CVE-2026-63825

What it actually does

This flaw affects Linux kernels built with GCC GCOV instrumentation enabled. GCOV counters are global rather than per-CPU, and GCC can optimize counter accesses in a way that mixes branch-counter values with loop-index calculations inside zlib's inflate_fast() routine. When multiple CPUs execute the same decompression path concurrently, one CPU can update the shared counter while another CPU is using it to calculate copy-loop bounds, producing inconsistent addresses and causing out-of-bounds kernel memory writes. The reported crash path occurs during IPComp packet decompression through the xfrm_ipcomp stack, reaching zlib_inflate() and inflate_fast(). The practical technical result is kernel memory corruption and denial of service, with potential confidentiality or integrity consequences depending on whether the out-of-bounds write can be shaped reliably on a vulnerable build.

Why it matters to the business

A remotely reachable Linux system using an affected GCOV-instrumented kernel could be crashed by crafted network traffic that triggers concurrent IPComp decompression. For organizations, this means possible outage of servers, network appliances, test kernels, CI kernels, debug builds, or specialized Linux deployments that enable kernel coverage instrumentation. Although the EPSS score is currently low and no known exploited status is reported, the CVSS rating is critical because exploitation does not require authentication or user interaction when the vulnerable network path is exposed. Production exposure may be limited because GCOV-enabled kernels are uncommon in standard distribution builds, but any externally reachable debug, validation, or custom kernel fleet should be treated as high priority.

How an attack unfolds

An attacker first identifies a Linux target that accepts IPsec/IPComp-related traffic and is running a kernel compiled with GCOV instrumentation. The attacker then sends crafted or repeated compressed IPComp traffic that causes multiple CPUs to execute the zlib inflate_fast() decompression loop at the same time. Because the vulnerable build uses non-atomic shared GCOV counter updates, concurrent execution can cause the compiler-generated counter loads to produce inconsistent loop base and bound values. The decompression routine can then write beyond the intended output buffer, resulting in a kernel page fault, panic, or memory corruption. There are no named threat actors, public exploit maturity, or KEV listing reported for this issue, so exploitation should currently be treated as plausible but not confirmed in the wild.

How to fix it

Apply a kernel update that includes the GCOV fix adding atomic profile counter updates where supported, specifically the build-system change that enables -fprofile-update=prefer-atomic for GCOV builds when it does not introduce unsupported libatomic dependencies. If vendor packages are used, upgrade to the first vendor-provided kernel version containing the fix. If maintaining custom kernels, rebuild affected GCOV-enabled kernels from a fixed source tree and verify the GCOV CFLAGS behavior during build. If immediate patching is not possible, reduce exposure by disabling IPComp where it is not required, restricting IPsec/IPComp traffic to trusted peers, avoiding GCOV-enabled kernels on exposed systems, and moving debug or coverage-instrumented kernels out of production-facing paths.

How to confirm the fix worked

Confirm whether running kernels are built with GCOV support by checking kernel configuration for CONFIG_GCOV_KERNEL or equivalent vendor build metadata. Confirm the deployed kernel source or package contains the fix that uses -fprofile-update=prefer-atomic for supported GCOV builds. For custom builds, inspect build logs or generated command lines to verify that GCOV compilation uses -fprofile-update=prefer-atomic on architectures where the compiler can inline the atomic update without libatomic. Validate exposure by reviewing whether IPComp/xfrm_ipcomp is enabled or loaded and whether untrusted networks can reach IPsec/IPComp services. After remediation, monitor for absence of recurring inflate_fast(), zlib_inflate(), ipcomp_decompress, or xfrm_input kernel crash traces under representative IPComp traffic tests.

Typical attack path

1. Identify Linux hosts or appliances that expose IPsec/IPComp processing to untrusted networks.
2. Determine or infer whether the target is running a custom, debug, CI, or coverage-instrumented kernel with GCOV enabled.
3. Send crafted IPComp traffic or repeated compressed payloads designed to drive concurrent decompression across multiple CPUs.
4. Trigger a race in global GCOV counter updates while inflate_fast() is calculating copy-loop bounds.
5. Cause an out-of-bounds kernel memory write leading to a kernel crash, service outage, or potentially exploitable memory corruption.

How to detect it

Look for evidence of kernel crashes or oops events in system logs, crash dumps, pstore records, kdump/vmcore artifacts, and centralized logging. Focus on traces that include inflate_fast(), zlib_inflate(), __deflate_decompress(), crypto_comp_decompress(), ipcomp_decompress, ipcomp_input, xfrm_input, or the xfrm_ipcomp module. Network telemetry may show bursts of IPComp or IPsec-related traffic shortly before the crash, especially from untrusted or unusual peers. Because the vulnerability is a race condition in instrumented kernel code, exploitation may leave no user-space process artifacts. A confirmed suspicious event would combine: a GCOV-enabled kernel, IPComp exposure, concurrent or repeated IPComp traffic, and a kernel crash trace matching the decompression call path. There are no public actor-specific indicators or malware artifacts associated with this CVE in the provided intelligence.

• BUG: unable to handle page fault for address:
• RIP: inflate_fast
• Call Trace:
• zlib_inflate
• __deflate_decompress
• crypto_comp_decompress
• ipcomp_decompress [xfrm_ipcomp]
• ipcomp_input [xfrm_ipcomp]
• xfrm_input
• __gcov0.inflate_fast+216
• xfrm_ipcomp
• CONFIG_GCOV_KERNEL
• -fprofile-update=prefer-atomic

What your security team should do

• Prioritize inventory of Linux systems running custom, debug, CI, fuzzing, validation, or coverage-enabled kernels; standard production distribution kernels may not be affected if GCOV is not enabled.
• Patch or rebuild all GCOV-enabled kernels from fixed kernel sources, especially systems exposed to untrusted network traffic.
• Disable or restrict IPComp unless there is a confirmed operational requirement.
• Review firewall and IPsec policy controls to ensure IPComp traffic is accepted only from trusted peers.
• Add monitoring for kernel oops, panic, and crash traces involving inflate_fast, zlib_inflate, ipcomp_decompress, xfrm_ipcomp, and xfrm_input.
• If crashes matching this pattern occurred, preserve vmcore, pstore, kdump, journal, and kernel logs for forensic review.
• Track vendor advisories for exact fixed kernel package versions, because no per-package fixed versions were provided in the input.