Linux Kernel Shared Zerocopy State Corruption in skb_tx_error()
CVE-2026-80977 is a Linux kernel networking vulnerability involving modification of shared zerocopy state in cloned socket buffers. skb_tx_error() prematurely completes the zerocopy user argument and clears SKBFL_ALL_ZEROCOPY, while skb_zcopy_downgrade_managed() clears SKBFL_MANAGED_FRAG_REFS. These fields reside in skb_shinfo(), which remains shared across clones. Open vSwitch can trigger the flaw through a non-final recirculation action: a flow miss on a clone modifies shared state while the original packet continues forwarding. SKBFL_DONT_ORPHAN preserves the shared fragments, and removal of SKBFL_SHARED_FRAG allows subsequent local IPsec ESP processing to decrypt in place over pages the packet does not privately own. The vulnerability participates in a local privilege-escalation chain also associated with CVE-2026-90049 and CVE-2026-89487.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Premature zerocopy completion can notify a producer that pages are reusable while another packet reference remains active. Clearing shared-fragment ownership markers can permit unauthorized in-place modification of shared pages during ESP decryption. In the associated Open vSwitch exploit chain, an unprivileged local attacker can modify resident page-cache contents of read-only, root-owned files and transiently replace executable contents to obtain root privileges. ESP authentication failure does not prevent the preceding decryption writes. These page-cache changes need not modify the on-disk file and can disappear after eviction or reboot. Successful privilege escalation compromises host confidentiality, integrity, and availability.
If you can’t patch tonight, do this now.
Where Open vSwitch is unnecessary, prevent its kernel module from loading using a module install prohibition rather than relying solely on blacklisting; address already-loaded modules separately. Where IPsec termination is unnecessary and ESP support is modular, prevent esp4 and esp6 from loading. Disabling unprivileged user namespaces removes the capability source used by the described local exploit chain, but can disrupt containers and application sandboxes. Restrict untrusted access to Open vSwitch configuration and the implicated zerocopy, recirculation, and local ESP processing paths until patched. These measures are configuration-dependent alternatives, not substitutes for the kernel update.
Patch, then assume compromise.
Install the distribution kernel security update addressing CVE-2026-80977 and reboot into the patched kernel. The correction skips shared zerocopy-state handling for cloned socket buffers and leaves final cleanup to skb_release_data() when the last shared-data reference is released. Apply the complete vendor update covering related Open vSwitch shared-fragment fixes rather than assuming this individual change resolves the entire exploit chain. SUSE kernel-default fixes include 4.12.14-122.336.1 for SLES 12 SP5 LTSS, 5.14.21-150400.24.246.1 for applicable SLE 15 SP4 branches, 5.14.21-150500.55.195.1 for applicable SP5 branches, 6.4.0-150600.23.143.1 for SP6 LTSS, and 6.4.0-150700.53.87.3 for SP7. Other products and kernel flavors require their corresponding vendor builds. Verify the running kernel after reboot.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
13 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.