CVE-2026-63825

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gcov: use atomic counter updates to fix concurrent access crashes<br /> <br /> GCC&amp;#39;s GCOV instrumentation can merge global branch counters with loop<br /> induction variables as an optimization. In inflate_fast(), the inner copy<br /> loops get transformed so that the GCOV counter value is loaded multiple<br /> times to compute the loop base address, start index, and end bound. Since<br /> GCOV counters are global (not per-CPU), concurrent execution on different<br /> CPUs causes the counter to change between loads, producing inconsistent<br /> values and out-of-bounds memory writes.<br /> <br /> The crash manifests during IPComp (IP Payload Compression) processing when<br /> inflate_fast() runs concurrently on multiple CPUs:<br /> <br /> BUG: unable to handle page fault for address: ffffd0a3c0902ffa<br /> RIP: inflate_fast+1431<br /> Call Trace:<br /> zlib_inflate<br /> __deflate_decompress<br /> crypto_comp_decompress<br /> ipcomp_decompress [xfrm_ipcomp]<br /> ipcomp_input [xfrm_ipcomp]<br /> xfrm_input<br /> <br /> At the crash point, the compiler generated three loads from the same<br /> global GCOV counter (__gcov0.inflate_fast+216) to compute base, start, and<br /> end for an indexed loop. Another CPU modified the counter between loads,<br /> making the values inconsistent - the write went 3.4 MB past a 65 KB<br /> buffer.<br /> <br /> Add -fprofile-update=prefer-atomic to CFLAGS_GCOV at the global level in<br /> the top-level Makefile, guarded by a try-run compile test. The test<br /> compiles a minimal program with and without -fprofile-update=prefer-atomic<br /> using the full KBUILD_CFLAGS, then compares undefined symbols in the<br /> resulting object files. If prefer-atomic introduces new undefined<br /> references (such as __atomic_fetch_add_8 on i386 or __aarch64_ldadd8_relax<br /> on arm64 with outline-atomics), the flag is not added -- the kernel does<br /> not link against libatomic.<br /> <br /> On architectures where GCC inlines 64-bit atomic counter updates (x86_64,<br /> s390, ...) the test passes and the flag is enabled, preventing the<br /> compiler from merging counters with loop induction variables and fixing<br /> the observed concurrent-access crash.<br /> <br /> On architectures where the flag would introduce libatomic dependencies, it<br /> is silently omitted and behaviour is no worse than before this patch.<br /> <br /> Move the CFLAGS_GCOV block from its original position (before the arch<br /> Makefile include) to after the core KBUILD_CFLAGS assignments but before<br /> the scripts/Makefile.gcc-plugins include. This placement ensures the<br /> try-run test sees arch-specific flags (-m32, -march=,<br /> -mno-outline-atomics) while avoiding GCC plugin flags (-fplugin=) that<br /> would break the test on clean builds when plugin shared objects do not yet<br /> exist.