CVE-2026-63825: Linux Kernel Race Condition Vulnerability

CVE-2026-63825 Overview

CVE-2026-63825 is a Linux kernel vulnerability in the GCOV code coverage instrumentation subsystem. GCC's GCOV instrumentation merges global branch counters with loop induction variables as a compiler optimization. In inflate_fast(), this optimization causes the compiler to reload the same global GCOV counter multiple times to compute loop bounds. Concurrent execution on different CPUs mutates the counter between loads, producing inconsistent values and out-of-bounds memory writes. The crash was observed during IP Payload Compression (IPComp) processing when inflate_fast() executed concurrently on multiple CPUs, writing 3.4 MB past a 65 KB buffer.

Critical Impact
Concurrent access to non-atomic GCOV counters allows out-of-bounds kernel memory writes, causing page faults and potential memory corruption in zlib_inflate and IPComp decompression paths.

Affected Products

Linux kernel builds compiled with CONFIG_GCOV_KERNEL enabled
Kernels using GCC GCOV instrumentation on SMP systems
IPComp (xfrm_ipcomp) and zlib decompression paths under concurrent load

Discovery Timeline

2026-07-19 - CVE-2026-63825 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-63825

Vulnerability Analysis

The defect is a race condition [CWE-362] in the interaction between GCC's GCOV instrumentation and the kernel's inflate_fast() zlib decompression routine. GCOV counters are global, not per-CPU, and updates are performed non-atomically by default. When GCC applies its counter-merging optimization, it treats the counter value as a loop induction variable and emits multiple loads of the same counter to compute base address, start index, and end bound of an indexed copy loop.

Under SMP execution, another CPU can modify the counter between these loads. The resulting inconsistent values cause the loop to compute an invalid address range and write far beyond the destination buffer. In the reported crash, the write extended 3.4 MB past a 65 KB buffer, triggering a page fault at inflate_fast+1431 during ipcomp_decompress.

Root Cause

The root cause is the absence of atomic semantics on GCOV counter updates combined with GCC's optimization of merging counter reads into induction variables. Because the counter is not read once and cached, and because updates are not atomic, concurrent execution produces torn reads and inconsistent computed bounds.

Attack Vector

The vulnerability manifests in kernels compiled with GCOV enabled that process network-delivered IPComp traffic. An attacker capable of sending IPComp-encapsulated traffic to a vulnerable host can drive concurrent inflate_fast() execution across CPUs, triggering the out-of-bounds write. Exploitation is limited to kernels built with coverage instrumentation, which is typically used in development and testing builds rather than production. The fix passes -fprofile-update=prefer-atomic to CFLAGS_GCOV in the top-level Makefile, guarded by a try-run compile test that verifies the flag does not introduce undefined references to libatomic symbols such as __atomic_fetch_add_8 or __aarch64_ldadd8_relax.

Detection Methods for CVE-2026-63825

Indicators of Compromise

Kernel page faults with the signature BUG: unable to handle page fault for address and RIP pointing inside inflate_fast
Call traces including zlib_inflate, __deflate_decompress, crypto_comp_decompress, ipcomp_decompress, and xfrm_input
Unexpected kernel oops or panic events on hosts receiving IPComp traffic under multi-CPU load

Detection Strategies

Audit build configurations for CONFIG_GCOV_KERNEL=y on any system exposed to untrusted network traffic
Correlate kernel crash reports with concurrent IPComp or zlib decompression activity
Monitor kernel logs for repeated faults referencing the same instrumented function across CPUs

Monitoring Recommendations

Forward /var/log/kern.log, dmesg, and kdump artifacts to a centralized logging platform for pattern analysis
Alert on repeated kernel oops events referencing decompression or xfrm_ipcomp paths
Track kernel version and build flags across the fleet to identify hosts running GCOV-instrumented kernels

How to Mitigate CVE-2026-63825

Immediate Actions Required

Apply the upstream kernel patch series referenced in the stable tree commits 49d893b9cbcf, 56cb9b7d96b2, and 5b959c1dbb45
Rebuild any GCOV-instrumented kernels after applying the updated top-level Makefile with -fprofile-update=prefer-atomic
Disable CONFIG_GCOV_KERNEL on production systems where coverage data is not required

Patch Information

The fix adds -fprofile-update=prefer-atomic to CFLAGS_GCOV globally in the top-level Makefile, guarded by a try-run compile test. The test compiles a minimal program with and without the flag using the full KBUILD_CFLAGS, then compares undefined symbols in the resulting object files. On architectures where GCC inlines 64-bit atomic counter updates (x86_64, s390), the flag is enabled. On architectures where it would introduce libatomic dependencies, it is silently omitted. See the upstream commits 49d893b9cbcf, 56cb9b7d96b2, and 5b959c1dbb45.

Workarounds

Rebuild the kernel with CONFIG_GCOV_KERNEL disabled if coverage instrumentation is not required
Disable IPComp (xfrm_ipcomp) on hosts running instrumented kernels until patches are applied
Restrict inbound IPsec/IPComp traffic at the network perimeter to limit exposure

bash

# Verify GCOV configuration in the running kernel
grep CONFIG_GCOV /boot/config-$(uname -r)

# Unload the IPComp module if not required
sudo modprobe -r xfrm_ipcomp

# Rebuild kernel without GCOV instrumentation
scripts/config --disable CONFIG_GCOV_KERNEL
make olddefconfig && make -j$(nproc)