CVE-2026-80977: net: skbuff: don't touch shared zerocopy state in skb_tx_error()
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: don't touch shared zerocopy state in skbtxerror()
skbtxerror() completes the zerocopy uarg and clears SKBFLALLZEROCOPY, and skbzcopydowngrademanaged() clears SKBFLMANAGEDFRAGREFS. Both live in skbshinfo(), 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 SKBFLSHAREDFRAG for an skb that is still in flight.
Open vSwitch reaches this with a non-last OVSACTIONATTRRECIRC: cloneexecute() sends a skbclone() into ovsdpprocesspacket() while doexecuteactions() keeps forwarding the original, and skbclone() does not privatise the frags here -- skborphanfrags() returns early on SKBFLDONTORPHAN. 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: skbreleasedata() clears the zerocopy state once the last reference to the shared data goes.
Affected Software
Event History
Frequently Asked Questions
Which deployments are most likely to be exposed?
The described path involves Open vSwitch processing a packet through a non-last OVS_ACTION_ATTR_RECIRC action, where a clone is sent into ovs_dp_process_packet() while the original continues forwarding. The harmful outcome described also requires later local ESP delivery that decrypts in place over shared fragments.
What conditions are needed to trigger the issue?
An attacker-controlled or otherwise triggering traffic path must cause a cloned skb to experience a flow miss while the original packet remains in flight. The affected clone must retain shared zerocopy state and fragment references, allowing the flow-miss processing to clear state on shared skb data.
Are all Linux kernel networking configurations affected by the described scenario?
No. The description identifies a specific Open vSwitch recirculation and skb-cloning path, followed by local ESP delivery. It does not establish that systems without this combination are affected.
What is the mitigation if an update cannot be applied immediately?
The provided information supports avoiding the described traffic path: non-last Open vSwitch OVS_ACTION_ATTR_RECIRC processing that clones packets, particularly where cloned-packet flow misses can occur and packets are later delivered locally for ESP processing. No other workaround is provided.
How can an administrator assess whether the vulnerable path is present?
Review Open vSwitch flows and actions for non-last OVS_ACTION_ATTR_RECIRC use, and determine whether those packets can take a clone flow-miss path while the original continues forwarding. Also determine whether affected traffic can subsequently undergo local ESP delivery.