Signal is active with 1 mentions in latest observed window
Immediate actions
Patch affected systems immediately
Recommended action window: Monitor and triage in normal cycle
NVD description
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: don't touch shared zerocopy state in skb_tx_error()
skb_tx_error() completes the zerocopy uarg and clears
SKBFL_ALL_ZEROCOPY, and skb_zcopy_downgrade_managed() clears
SKBFL_MANAGED_FRAG_REFS. Both live in skb_shinfo(), which every clone
shares, while the caller only owns the reference it is about to drop.
Through a clone it tells the producer its pages are free and drops
SKBFL_SHARED_FRAG for an skb that is still in flight.
Open vSwitch reaches this with a non-last OVS_ACTION_ATTR_RECIRC:
clone_execute() sends a skb_clone() into ovs_dp_process_packet() while
do_execute_actions() keeps forwarding the original, and skb_clone()
does not privatise the frags here -- skb_orphan_frags() returns early
on SKBFL_DONT_ORPHAN. A flow miss on the clone then strips the marker
from the packet still being forwarded, and a later local ESP delivery
decrypts in place over frags it does not own privately.
Skip it for a cloned skb. Nothing is lost: skb_release_data() clears
the zerocopy state once the last reference to the shared data goes.
Peaked 1d ago at 1 mentions (2026-09-17); latest day: 1
2 total mentions across 2 days
Deep dive
>Activity timeline2 mentions / 2d
>Signal classification2 categories
Disclosure
150.0%
Patch
150.0%
>Classification over time
Date
Total
Labels
2026-09-17
1
Disclosure1
2026-09-18
1
Patch1
>Full discourse2 posts
DFIR Lab@DFIR_Lab·
Patch
🚨 HIGH: CVE-2026-80977 in Linux kernel (CVSS 7.8)
Zerocopy state handling flaw allows local privilege escalation. Affects skb_tx_error() function in net/skbuff.
Patch immediately.
#CVE#Vulnerability#PatchNow#ThreatIntel https://t.co/3qmsNcjwTL
Post summary
The text announces a high-severity Linux kernel CVE with technical vulnerability details and an explicit instruction to patch immediately. No PoC, exploit tool, active exploitation, or debunking claim is stated.
New LPE bug family: Open vSwitch strips SKBFL_SHARED_FRAG from a live forwarded skb, reopening the Fragnesia page-cache write primitive. Deterministic root on default Arch, Fedora, Debian, Amazon Linux, and RHEL with no race condition required.
Tracked as CVE-2026-90049, CVE-2026-89487, and CVE-2026-80977. Public since 2026-08-13, fixed in mainline and stable on 2026-09-04. Actively exploitable on unpatched kernels today.
- Root cause is in queue_userspace_packet() inside net/openvswitch/datapath.c. When an OVS upcall fails, skb_tx_error() calls skb_zcopy_clear(), which clears the entire SKBFL_ALL_ZEROCOPY group including SKBFL_SHARED_FRAG. Because do_execute_actions() ignores the upcall return value, the same skb, now missing its ownership marker but still carrying foreign page-cache frags, continues down the action pipeline to OUTPUT. If that output reaches esp_input(), the gate at skb_has_shared_frag() passes and the in-place AES-GCM decrypt writes attacker-controlled plaintext directly into the page-cache folio.
- Exploitation requires three things an unprivileged user can satisfy: CAP_NET_ADMIN inside a user namespace (GENL_UNS_ADMIN_PERM on all OVS genl ops, so unshare -Urn is enough), openvswitch.ko autoloading on first genl family resolution (no CAP_SYS_MODULE needed), and an MSG_ZEROCOPY send over a PROT_READ MAP_SHARED mapping of a root-owned file so SKBFL_DONT_ORPHAN keeps the page-cache frag from being copied during the upcall.
#DFIR_Radar
Post summary
This is a detailed vulnerability disclosure of a new Open vSwitch LPE bug family (CVE-2026-90049, CVE-2026-89487, CVE-2026-80977) explaining the root cause, exploitation chain, and fix date, without naming a PoC, exploit tool, or specific patch version.
