Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain on-path network visibility to target
-
ExploitInduce condition that reaches unreadable skb frags
-
ExecutionKernel emits ICMP quote / TX buffer with stale bytes
-
ImpactCapture packets carrying uninitialized kernel memory
Vulnerability Assessment
| Exploitation Conditions | Requires the kernel to reach the unreadable-fragment branch of skb_copy_and_csum_bits() - i.e. an skb whose frags are not CPU-readable, as arises with unreadable/devmem skb fragment handling added in the 6.12-era networking code - and for the result to flow into a wire-bound buffer that is not pre-zeroed: either an ICMP error quoting the offending packet or a TX bounce buffer via skb_copy_and_csum_dev(). Exploitation is materially LIMITED by: (1) the specialized, non-default networking configuration needed to produce unreadable frags; (2) the leaked data being whatever already occupied the reused buffer, not attacker-chosen memory; (3) the corrupted checksum, which causes most receivers to drop the packet, so reliable capture needs passive on-path observation rather than normal delivery; (4) applicability only to kernels carrying the vulnerable code (roughly 6.12 up to the listed fixed versions). |
| Impact | Signals point to a real but low-urgency defensive-hardening fix rather than an actively dangerous flaw. The supplied CVSS 3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/C:H) frames this as a trivially remote, unauthenticated, high-confidentiality disclosure - but that rating conflicts with the described mechanism and should be treated with caution. The leak only occurs when skb_copy_and_csum_bits() reaches UNREADABLE frags (the devmem/unreadable-skb-fragment code path introduced around kernel 6.12); this is a specialized, non-default condition, so the AC:L in the supplied vector likely understates real attack complexity - verify the trigger path with the kernel maintainers. The exposure is also self-limiting: the kernel's own note says the checksum usually will not match the stale data, so most receivers drop the packet, and the leaked bytes are whatever happened to be in a reused ICMP-quote or TX bounce buffer, not attacker-selected memory. Corroborating lower-priority signals: EPSS is 0.21% (11th percentile), there is no CISA KEV listing, and no public exploit or PoC reference is present - only the fix commits. The vuln.today decision label is 'this_week', consistent with routine stable-kernel patching rather than emergency response. Net: a genuine kernel memory-disclosure bug worth patching in the normal cycle, but the high CVSS overstates real-world risk given the niche precondition and self-limiting leak behavior. |
| Exploit ScenarioDerived | On a host whose networking stack produces skbs with unreadable fragments (e.g. devmem TCP paths), the kernel builds an ICMP error quoting an offending packet, or a driver bounce buffer in skb_copy_and_csum_dev(), and skb_copy_and_csum_bits() stops after the linear part, leaving prior buffer contents in the remainder. An attacker positioned to observe the resulting network traffic captures those stale kernel bytes. No public exploit or PoC code is identified at time of analysis, and the trigger path itself is not described as attacker-controllable in the available sources. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
Information disclosure in the Linux kernel networking stack: when skb_copy_and_csum_bits() hits unreadable skb fragments it copies only the linear portion and returns 0, leaving the rest of the caller's buffer holding whatever was already in memory - and that buffer is then transmitted (an ICMP error quoting the offending packet, or a driver TX bounce buffer reached via skb_copy_and_csum_dev()). Kernels carrying the vulnerable code, roughly the 6.12 branch up to the fixed releases 6.12.113, 6.18.57, 7.2.11 and 7.3, are affected, but the leak only becomes reachable with the specialized, non-default configuration that produces unreadable/devmem fragments. No public exploit has been identified at time of analysis, EPSS is low at 0.21% (11th percentile), and because the resulting checksum usually no longer matches the data most receivers drop the packet, so the practical exposure is limited to passive on-path observation of stale buffer contents rather than attacker-chosen memory.
RemediationAI
Vendor-released patches are available: update to Linux 6.12.113, 6.18.57, 7.2.11 or 7.3, each of which contains the change that zeroes the unfilled portion of the destination buffer (with the negative-length guard). The corresponding upstream stable commits are git.kernel.org/stable/c/ab9414ed70bd783e902a85c350620dee269bcb2b, git.kernel.org/stable/c/5551399751e2c9f31e4f3428040985a07e79d9c2, git.kernel.org/stable/c/39d1a6b601831237c6038b5e3ac8dbb883c1700a and git.kernel.org/stable/c/5f19b9cfff79508e8cb09be40d014cb0807f3854; distributions and downstream vendors that backported the unreadable-fragment networking code should be tracked through their own advisories referencing CVE-2026-99030 / EUVD-2026-108825 (nvd.nist.gov/vuln/detail/CVE-2026-99030). Where immediate kernel upgrades are not possible, the exposure is gated by the non-default unreadable/devmem skb fragment configuration, so keeping that feature disabled on untrusted-network-facing systems removes the reachable path at the cost of losing the associated zero-copy fragment handling - a trade-off that must be validated against the workload's networking requirements, and one that does not substitute for installing the fixed kernel.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
skb_copy_and_csum_bits() in net/core/skbuff.c walks an skb's linear area plus its fragment list, copying payload into a caller-supplied buffer while folding a checksum over the copied bytes. The 6.12-era networking work that introduced unreadable (devmem / non-CPU-readable) skb fragments added a bail-out path: when the function reaches frags it cannot read, it returns 0 after filling only the linear part, leaving the tail of the destination buffer untouched. Both call sites use non-zeroed destinations that go straight out on the wire - the ICMP error path that quotes the packet that triggered the error, and skb_copy_and_csum_dev(), which builds a driver TX bounce buffer. The fix zeroes the portion of the buffer that was not filled, guarded so that a negative @len from a broken caller cannot be turned into a huge memset(). No CWE class was assigned in the source data; the defect is best characterized as transmission of stale buffer contents (uninitialized/stale-memory data exposure) rather than a memory-safety corruption. Two constraints bound the impact: the disclosed bytes are whatever previously occupied the reused buffer, not memory the attacker selects, and the copied checksum generally will not validate against the zeroed data, so ordinary receivers discard the frame. Reaching the branch at all requires the non-default unreadable-fragment configuration, and the flaw applies only to kernels containing the vulnerable code - the trigger specifics beyond that are not described in the available sources.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Disclosure crosses the network so AV:N/PR:N, but it depends on the uncommon unreadable-frag path and yields only limited uninitialized bytes, so AC:H and C:L; no integrity or availability impact.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits()
When skb_copy_and_csum_bits() reaches unreadable frags it returns 0 after copying only the linear part, and the rest of the caller's buffer is left as it was. The callers copy into a buffer that is about to go out on the wire: an ICMP error quoting the offending packet, or a driver's TX bounce buffer in skb_copy_and_csum_dev(). Neither buffer is zeroed beforehand, so whatever was in memory there gets sent.
Zero the part of the buffer we didn't fill. The checksum usually won't match the data any more, so the receiver will usually drop the packet, but either way it no longer carries anything it shouldn't. Only zero for a positive @len, a negative one from a broken caller must not turn into a huge memset().
Executive ViewAI
A high-severity information disclosure flaw in the Linux kernel networking stack (CVE-2026-99030) can leak stale kernel memory contents into network packets under a specialized, non-default configuration. While no public exploit exists and practical exposure is limited to passive observation, affected systems could inadvertently disclose sensitive data remnants to on-path observers. Leadership should prioritize patching internet-facing Linux servers to eliminate this residual data leakage risk.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
EUVD-2026-108825
GHSA-2m74-g73v-pv5c
NVD
CVE.org
EPSS
Exploit-DB