CyberSecBulletin
CVE-2026-63825NVD status: Analyzed

Linux: Out-of-bounds Write

Published Updated By the CyberSecBulletin desk

CVE-2026-63825 is a critical-severity out-of-bounds write vulnerability in Linux, with a CVSS 3.1 base score of 9.8 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists versions 76cb9fde95eba4bd8f06d142a8b8810bf2d09de4, b0f7bd5eeb903a0021a80e9d704814e2a9d3998c, 4575852c23a10abc7648d31e4c12cf79d7391637 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.48% chance of exploitation within 30 days, which is low compared with other CVEs.

Patch this week

Critical severity: a successful attack would have severe impact.

What to do

  1. Update Linux to 76cb9fde95eba4bd8f06d142a8b8810bf2d09de4 or b0f7bd5eeb903a0021a80e9d704814e2a9d3998c or 4575852c23a10abc7648d31e4c12cf79d7391637 or 49d893b9cbcfc5802a32e53a64c6c6956670d65b, whichever matches your release line, or a later version.
  2. Update Linux Kernel to 6.1.191 or 6.6.160 or 6.12.114 or 6.18.38, whichever matches your release line, or a later version.
  3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinux2521f2c228ad750701ba4702484e31d876dbc386 up to, but not including, 76cb9fde95eba4bd8f06d142a8b8810bf2d09de4; 2521f2c228ad750701ba4702484e31d876dbc386 up to, but not including, b0f7bd5eeb903a0021a80e9d704814e2a9d3998c; 2521f2c228ad750701ba4702484e31d876dbc386 up to, but not including, 4575852c23a10abc7648d31e4c12cf79d7391637; 2521f2c228ad750701ba4702484e31d876dbc386 up to, but not including, 49d893b9cbcfc5802a32e53a64c6c6956670d65b; 2521f2c228ad750701ba4702484e31d876dbc386 up to, but not including, 5b959c1dbb4522b9e3ac4e26ad638b8784869841; 2521f2c228ad750701ba4702484e31d876dbc386 up to, but not including, 56cb9b7d96b28a1173a510ab25354b6599ad3a33; 2.6.3176cb9fde95eba4bd8f06d142a8b8810bf2d09de4, b0f7bd5eeb903a0021a80e9d704814e2a9d3998c, 4575852c23a10abc7648d31e4c12cf79d7391637, 49d893b9cbcfc5802a32e53a64c6c6956670d65b, 5b959c1dbb4522b9e3ac4e26ad638b8784869841, 56cb9b7d96b28a1173a510ab25354b6599ad3a33
LinuxLinux Kernel2.6.31 up to, but not including, 6.1.191; 6.2 up to, but not including, 6.6.160; 6.7 up to, but not including, 6.12.114; 6.13 up to, but not including, 6.18.38; 6.19 up to, but not including, 7.1.36.1.191, 6.6.160, 6.12.114, 6.18.38, 7.1.3

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.

Official description

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

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Out-of-bounds Write

The product writes data past the end, or before the beginning, of the intended buffer.

How developers prevent this class of flaw

  • Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer. Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Examples include the Safe C String Library (SafeStr) by Messier and Viega, and the Strsafe.h library from Microsoft. These libraries provide safer versions of overflow-prone string-handling functions.
  • Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND discusses canary-based detection in detail.

More Out-of-bounds Write vulnerabilities (CWE-787)

Timeline

  1. CVE record published.
  2. Record last changed materially (score, affected products, status or references).

References

Recent Out-of-bounds Write vulnerabilities

Spotted an error? Tell us.