Re: Binary size increase for -fsanitize=return in production

0 views
Skip to first unread message

Andrew Grieve

unread,
Mar 12, 2026, 9:43:54 PMMar 12
to Mikihito Matsuura, binar...@chromium.org, Stephen Nusko, agr...@chromium.org
Yep, seems fine to me. The bot limit is just to alert of significant changes to make sure they don't go unnoticed. It makes perfect sense that this would increase size, and you're the best judge as to whether there is value here. Sounds like there is.

On Thu, Mar 12, 2026 at 9:17 PM Mikihito Matsuura <mi...@google.com> wrote:
Hi binary-size team,

I would like to enable `-fsanitize=return` globally across all platforms, including those where `optimize_for_size=true`.
CQ shows +24,524 bytes for the Android binary size.

Security Benefits
This sanitizer allows the build to detect when a value-returning function falls off the end of a switch statement that fully enumerates its enum values but lacks a default case.
This specific pattern was responsible for a major past security issue (crbug/453094710).

Binary Size Impact
The current observed increase for Android is as follows:
*   Android (arm32): +24,524 bytes
*   Android (arm64 high end): +366,040 bytes

https://crrev.com/c/7629258

While the arm32 increase currently exceeds the 16 KiB limit, we have seen that these figures can change significantly later due to PGO.

Given the high security value of catching these undefined behaviors, is this binary size hit acceptable for all platforms?
I will share the binary size with PGO once it has landed.

Thanks,
Mikihito

Stephen Nusko

unread,
Mar 12, 2026, 10:11:46 PMMar 12
to Andrew Grieve, chrome-memory-safety, Chrome CPP Runtime Safety, Mikihito Matsuura, binar...@chromium.org, Ryan Lothian
> While the arm32 increase currently exceeds the 16 KiB limit, we have seen that these figures can change significantly later due to PGO.

I think pgo only applies to the high end build, but I still think the 24kb is likely worth it.

To add context for the value of the sanitize, the particular bug Mikihito linked resulted in a arbitrary jump yielding remote code execution in a unsandboxed process (with a PoC) which awarded 250k USD VRP award, so closing down that avenue quickly I think is worth the gain versus trying to find and patch all the locations individually (and might catch other cases we'd miss).


Cheers,
Stephen
Reply all
Reply to author
Forward
0 new messages