CVE-2026-80977

What it actually does

A use-after-free and shared-state corruption bug in the Linux kernel networking stack. skb_tx_error() completes zerocopy uarg state and clears SKBFL_ALL_ZEROCOPY (and related helpers clear SKBFL_MANAGED_FRAG_REFS) in skb_shinfo(), which every skb clone shares. The caller only owns the reference it is about to drop, so a clone can tell the producer pages are free and drop SKBFL_SHARED_FRAG while another skb using those fragments is still in flight. Subsequent in-place transforms (notably local ESP decrypt) then operate on fragments they do not privately own, yielding use-after-free, double-free of pages, or kernel memory corruption. The issue is reachable via Open vSwitch when a non-last OVS_ACTION_ATTR_RECIRC path skb_clone()s a packet without privatizing fragments (skb_orphan_frags() returns early on SKBFL_DONT_ORPHAN).

Why it matters to the business

A local, low-privileged user or process can panic the host or, with further memory corruption, obtain kernel-equivalent control, fully compromising confidentiality, integrity, and availability of the machine and any workloads on it. Systems that forward packets through Open vSwitch recirculation, use zerocopy transmit, or perform in-place IPsec/ESP are the most exposed. There is no CISA KEV listing, no known ransomware use, and exploit maturity is none; EPSS remains very low (~0.00176, flat over 30 days). Even so, CVSS 7.8 (local, low complexity, high CIA) and kernel-level impact justify prompt patching of Linux hosts—especially hypervisors, virtual switches, and packet-processing nodes—rather than waiting for in-the-wild activity. The advisory is about 20 days old.

How an attack unfolds

An attacker who already has local unprivileged access on a vulnerable Linux host induces packet processing that clones an skb without privatizing its fragments—most naturally via Open vSwitch recirculation (clone_execute() feeding a clone into ovs_dp_process_packet() while do_execute_actions() continues forwarding the original). A flow miss or transmit-error path on the clone runs skb_tx_error(), which mutates shared zerocopy flags in skb_shinfo() and signals the producer that pages may be reused. The original skb remains in flight. A later local ESP (or similar in-place) delivery then decrypts over fragments that are no longer privately owned, triggering a kernel use-after-free. That fault can crash the system immediately or, in a prepared memory layout, be abused for privilege escalation. No named threat actors or campaigns are associated with this CVE, and no public exploit maturity is reported.

How to fix it

Apply the upstream Linux kernel fix that skips zerocopy-state mutation in skb_tx_error() when the skb is cloned, leaving cleanup to skb_release_data() when the last reference to the shared data drops. Install the vendor/distribution kernel update that contains this change; no per-package fixed versions were listed in the provided advisory, so use the distro security tracker for CVE-2026-80977 (or the equivalent stable-commit backport) to select the correct kernel package. If you cannot patch immediately, restrict local unprivileged access, limit who can inject or recirculate traffic into Open vSwitch datapaths, and avoid combining OVS recirculation with zerocopy/shared-frag and in-place ESP/IPsec on unpatched kernels. Reboot into the patched kernel to make the fix active.

How to confirm the fix worked

Confirm the running kernel changelog, distro CVE tracker, or package changelog lists CVE-2026-80977 or the skb_tx_error() cloned-skb guard. After upgrade, verify uname -r matches a patched build and that the host has been rebooted onto it. Inventory systems running Open vSwitch, kernel IPsec/ESP, and zerocopy networking as higher-priority exposure. On a patched tree, skb_tx_error() must not complete or clear shared zerocopy state for cloned skbs; last-reference teardown via skb_release_data() remains the only cleanup. Absence of a matching vendor advisory for a given kernel series should be treated as still-vulnerable until confirmed otherwise.

Typical attack path

1. Obtain local unprivileged access on a Linux host that processes packets with shared/zerocopy sk_buff fragments (commonly Open vSwitch plus in-place transforms such as ESP).
2. Cause a clone of an in-flight skb without fragment privatization, e.g. a non-last OVS recirculation action so the clone and original share skb_shinfo() zerocopy state.
3. Trigger a transmit-error or flow-miss path on the clone so skb_tx_error() completes shared zerocopy state and clears shared flags while the original skb is still being forwarded.
4. Force subsequent in-place use of the original skb (for example local ESP decrypt) against fragments the kernel no longer treats as privately owned.
5. Resulting kernel use-after-free causes a panic or, if successfully corrupted, elevated privileges on the host.

How to detect it

This is a kernel use-after-free with no userland payload signature; look for whether it already fired rather than for a distinct implant. Review dmesg, journalctl -k, /var/log/kern.log, and kdump/vmcore from the publication date onward for oops/panic with networking call traces involving skb_tx_error, skb_release_data, Open vSwitch action execution (clone_execute, do_execute_actions, ovs_dp_process_packet), or in-place xfrm/ESP decrypt. Sudden host reboots, hung vswitch datapaths, or page-allocator/bad-page-state warnings coincident with OVS recirculation or local IPsec delivery are worth correlating. There are no named APT campaigns to hunt. Absence of oops does not prove non-exploitation if the host panicked without crash dump collection.

• skb_tx_error
• skb_zcopy
• SKBFL_ALL_ZEROCOPY
• clone_execute
• ovs_dp_process_packet
• do_execute_actions
• OVS_ACTION_ATTR_RECIRC
• Unable to handle kernel paging request
• BUG: unable to handle page fault
• Bad page state
• net/core/skbuff.c
• esp_input
• xfrm_input

What your security team should do

• Patch and reboot Linux kernels to a build that includes the skb_tx_error() cloned-skb zerocopy guard; treat OVS, IPsec/ESP, and packet-forwarding hosts as first-wave.
• Until patched, reduce local unprivileged access and restrict who can recirculate or inject packets into Open vSwitch datapaths.
• Track distro security advisories for this CVE because no exact fixed package versions were supplied with the input.
• Prioritize by role (hypervisors, virtual switches, gateways) rather than EPSS; likelihood is currently low but impact is kernel-wide.
• Ensure kdump/vmcore and persistent journal collection are enabled so any pre-patch oops can be triaged.
• Re-scan the fleet after the patch window to confirm no hosts remain on unpatched kernels.