Re: [PATCH 1/1] lib/zlib: use atomic GCOV counters to prevent crash in inflate_fast

[Peter Oberparleiter]

On 30.03.2026 16:32, Konstantin Khorenko wrote:
> GCC's GCOV instrumentation can merge global branch counters with loop
> induction variables as an optimization. In inflate_fast(), the inner
> copy loops can be transformed so that GCOV counter values participate
> in computing loop addresses and bounds. Since GCOV counters are global
> (not per-CPU), concurrent execution on different CPUs causes the counter
> to change mid-computation, producing inconsistent address calculations
> and out-of-bounds memory writes.
> 
> The crash manifests during IPComp (IP Payload Compression) processing
> when inflate_fast() runs concurrently on multiple CPUs:
> 
>   BUG: unable to handle page fault for address: ffffd0a3c0902ffa
>   RIP: inflate_fast+1431
>   Call Trace:
>    zlib_inflate
>    __deflate_decompress
>    crypto_comp_decompress
>    ipcomp_decompress [xfrm_ipcomp]
>    ipcomp_input [xfrm_ipcomp]
>    xfrm_input
> 
> In one observed case, the compiler merged a global GCOV counter with the
> loop induction variable that also indexed stores. Another CPU modified
> the counter between the setup and iteration phases, causing a write
> 3.4 MB past the end of a 65 KB buffer.
> 
> The kernel already uses -fno-tree-loop-im for GCOV builds (commit
> 2b40e1ea76d4) to prevent a different optimization issue. That flag
> prevents GCC from hoisting loop-invariant memory operations but does
> NOT prevent the IVopts pass from merging counters with induction
> variables.
> 
> Add -fprofile-update=atomic to zlib Makefiles. This tells GCC that
> GCOV counters may be concurrently accessed, causing counter updates to
> use atomic instructions (lock addq) instead of plain load/store.
> This prevents the compiler from merging counters with loop induction
> variables. The flag is scoped to zlib only to minimize performance
> overhead from atomic operations in the rest of the kernel.
> 
> Signed-off-by: Konstantin Khorenko <khorenko@xxxxxxxxxxxxx>
> Reviewed-by: Vasileios Almpanis <vasileios.almpanis@xxxxxxxxxxxxx>
> Reviewed-by: Pavel Tikhomirov <ptikhomirov@xxxxxxxxxxxxx>

I'm all for introducing -fprofile-update=atomic to GCOV CFLAGS as it not
only addresses this bug, but makes coverage data more consistent
overall. My only suggestion would be to apply it at global scope
(top-level Makefile), not restricting it to zlib alone. Since
GCOV-instrumented kernels already have a significant performance hit due
to the added profiling code, this side-effect of using atomic
instructions can IMO be safely ignored.

Unfortunately, while compile-testing this suggested change to the global
Makefile, I ran into the following build assert which needs more
investigation:

net/core/skbuff.c:5163:9: note: in expansion of macro ‘BUILD_BUG_ON’
 5163 |         BUILD_BUG_ON(skb_ext_total_length() > 255);


-- 
Peter Oberparleiter
Linux on IBM Z Development - IBM Germany R&D