Raw vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HSummary
CVE-2026-31641 is a high-severity Out-of-bounds Read (CWE-125) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 4th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-8 (Security and Privacy Engineering Principles) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-31641 is a heap buffer overflow vulnerability in the Linux kernel's RxRPC implementation, specifically in the rxrpc_preparse_xdr_yfs_rxgk() function used for RxGK token loading. The issue arises when parsing XDR tokens: raw key and ticket lengths are read as u32 values and passed through round_up(x, 4) for validation and allocation. If a raw length is >= 0xfffffffd, round_up() wraps around to 0, causing the bounds check and kzalloc to use a zero size while the subsequent memcpy copies the original approximately 4 GiB value, resulting in the overflow. This affects Linux kernel versions prior to the application of the referenced stable patches.
The vulnerability is exploitable by a local unprivileged attacker via an add_key() system call, requiring low privileges (PR:L), low attack complexity (AC:L), and no user interaction (UI:N) in a local context (AV:L) with no scope change (S:U). Successful exploitation can lead to high impacts on confidentiality, integrity, and availability (C:H/I:H/A:H), with a CVSS v3.1 base score of 7.8. The control path for valid tokens with lengths within bounds remains unaffected.
Mitigation involves applying the upstream kernel patches from the provided stable commit references: https://git.kernel.org/stable/c/3e04596cba8a86cbff9c3f4bf0a524a3a488773c, https://git.kernel.org/stable/c/49875b360c2b83a3c226e189c502e501d83e6445, and https://git.kernel.org/stable/c/d179a868dd755b0cfcf7582e00943d702b9943b8. These fixes reject raw key lengths above AFSTOKEN_GK_KEY_MAX and ticket lengths above AFSTOKEN_GK_TOKEN_MAX before rounding, size flexible-array allocations using struct_size_t() based on validated raw lengths, and cache raw lengths to prevent time-of-check-to-time-of-use (TOCTOU) issues during later memcpy operations. The vulnerability is associated with CWE-125.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-25534
Vulnerability Data
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix RxGK token loading to check bounds rxrpc_preparse_xdr_yfs_rxgk() reads the raw key length and ticket length from the XDR token as u32 values and passes each through round_up(x, 4)…
more
before using the rounded value for validation and allocation. When the raw length is >= 0xfffffffd, round_up() wraps to 0, so the bounds check and kzalloc both use 0 while the subsequent memcpy still copies the original ~4 GiB value, producing a heap buffer overflow reachable from an unprivileged add_key() call. Fix this by: (1) Rejecting raw key lengths above AFSTOKEN_GK_KEY_MAX and raw ticket lengths above AFSTOKEN_GK_TOKEN_MAX before rounding, consistent with the caps that the RxKAD path already enforces via AFSTOKEN_RK_TIX_MAX. (2) Sizing the flexible-array allocation from the validated raw key length via struct_size_t() instead of the rounded value. (3) Caching the raw lengths so that the later field assignments and memcpy calls do not re-read from the token, eliminating a class of TOCTOU re-parse. The control path (valid token with lengths within bounds) is unaffected.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V5.2.6
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation directly finds out-of-bounds read flaws through static analysis, fuzzing, and dynamic bounds checks.
Secure engineering principles require bounds checking and memory-safe constructs that stop out-of-bounds reads from being introduced.
Process isolation confines the effects of an out-of-bounds read to the compromised process.
Input validation rejects malformed indices or lengths that would otherwise cause reads outside buffer bounds.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure-development practices such as bounds checking and memory-safe languages directly prevent out-of-bounds reads.
Vulnerability scanning and recording can discover instances of out-of-bounds reads after code is deployed.
Routine patching replaces vulnerable code containing out-of-bounds read flaws.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development and acceptance includes fuzzing and static analysis that detect out-of-bounds read defects before release.
Logging can record evidence of an out-of-bounds read but does not prevent the weakness itself.
Secure development life cycle mandates input validation and bounds checking that directly prevent out-of-bounds reads.
Application security requirements include explicit bounds and memory-safety specifications that mitigate buffer over-reads.
Secure system architecture and engineering principles require memory-safe design patterns and runtime protections against out-of-bounds access.
Secure coding standards explicitly forbid unsafe pointer arithmetic and mandate bounds-checked reads, eliminating CWE-125.