Linux Kernel Unspecified Vulnerability
Exploited since 2026-08-27. No WAF vendor names it yet.
In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen),… More
In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 ("ipv6: avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.
Edge coverage
Claimed by vendorsAsk Vigil
AI · answers from this pageWorkers AI (Llama 3.3). Can be wrong: check the cited source.
Severity, decoded
CVSS 3.1Exploitable with local access, with low privileges and no user interaction, leading to full loss of confidentiality, integrity and availability.
How the score is built
- Attack vectorAn attacker needs local access, or must trick a user into opening something on the machine.Local
- Attack complexityNo special conditions are needed; the attack works reliably.Low
- Privileges requiredThe attacker needs an ordinary user account.Low
- User interactionNo one has to click or open anything; the attack works on its own.None
- ScopeThe damage stays within the vulnerable component.Unchanged
- Confidentiality impactAn attacker can read all data the affected component holds, or the most sensitive parts of it.High
- Integrity impactAn attacker can change any data or files the affected component protects.High
- Availability impactAn attacker can take the component down completely or keep it from serving anyone.High
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HAttackers are exploiting this in the wild.
At least one step needs hands-on work, which slows mass attacks.
A successful attack gives full control over the affected software or all of its data.
Public exploits
None foundNo exploit in Exploit-DB or Metasploit, and no scanner template. That lowers, but doesn't remove, the chance of mass exploitation.
Timeline
- 2026-07-04CVE publishedCVE List
- 2026-08-27Added to CISA KEVConfirmed exploitation in the wild
Vendor statements
QuotedCloudflareWAF Managed Rules
We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it. Each row gives the rule ID and its default action. The feed starts in January 2025, so older rules are missing.
AWSAWS WAF Managed Rules
We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it. AWS often describes a vulnerability without naming its CVE (for example "Log4j"). We count only entries that name the CVE, so AWS coverage is understated.
Microsoft AzureFront Door and Application Gateway WAF (DRS)
We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it. The rule tables name CVEs but carry no dates, so Azure is left out of every time-to-rule figure.
Google CloudCloud Armor preconfigured WAF rules
We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it. Google names few CVEs: the release notes start in May 2024 and the rules reference lists CVEs without dates. Its cve-canary rules are opt-in.
FastlyNext-Gen WAF virtual patches
The CVE predates the oldest entry in this vendor's public feed, so a rule may exist that we cannot see.
F5Attack signatures (Distributed Cloud WAF)
We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it. Each signature lists the CVEs it references, with its id and date. F5 does not state a default action; signatures enforce once staging ends in your policy.
AkamaiApp & API Protector (Adaptive Security Engine)
This vendor publishes no machine-readable rule changelog we can check.
OWASP CRSCore Rule Set (open source, used inside many WAFs)
We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it. CRS rarely names CVEs: it relies on generic detections. Our own lab measures what it actually blocks.
Social
No posts seen yet on X, Bluesky, Mastodon, Hacker News or GitHub.