CVE-2026-89487: openvswitch: only skb_tx_error() a packet we are about to drop
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: only skbtxerror() a packet we are about to drop
queueuserspacepacket() borrows the packet skb -- it only copies it into a private netlink message (userskb) and does not own it; on return doexecuteactions() keeps forwarding it through the flow's remaining actions. Its error path nevertheless calls skbtxerror(skb), which via skbzcopyclear() does skbshinfo(skb)->flags &= ~SKBFLALLZEROCOPY, stripping SKBFLSHAREDFRAG from that live skb (skbtxerror()'s kerneldoc says "skb must be freed afterwards").
For a MSGZEROCOPY skb carrying page-cache frags, SKBFLSHAREDFRAG is what makes espinput() skbcowdata() before in-place AEAD; once it is stripped a later local ESP-in-UDP delivery decrypts in place over pages the sender does not own -- an unprivileged page-cache write (the "Fragnesia" primitive). doexecuteactions() ignores outputuserspace()'s return value, so any action after a failed USERSPACE upcall inherits the stripped skb.
Move the skbtxerror() to the flow-miss drop path - the "default" branch of ovsdpprocesspacket()'s switch(error), before kfreeskb().
The call has been here since commit 36d5fe6a0007 ("core, nfqueue, openvswitch: Orphan frags in skbzerocopy and handle errors") but was harmless until espinput() began relying on SKBFLSHAREDFRAG to gate in-place decrypt; only then did stripping it on a still-forwarded skb become a page-cache write primitive.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.157.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.190-1Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.13-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Compensating control
Move skb_tx_error() out of queue_userspace_packet()'s error path and call it only in the default flow-miss drop branch of ovs_dp_process_packet()'s switch(error), immediately before kfree_skb().
Event History
Frequently Asked Questions
What conditions are required for exploitation?
The packet must be a MSG_ZEROCOPY skb carrying page-cache fragments. Exploitation also requires a failed Open vSwitch USERSPACE upcall followed by later packet processing that reaches local ESP-in-UDP delivery, where decryption can occur in place.
Who could exploit this?
The described impact is an unprivileged page-cache write. The affected packet path involves Open vSwitch processing of a live skb after a USERSPACE upcall failure rather than a packet that is immediately dropped.
Does every failed USERSPACE upcall cause the issue?
No. The problem arises when packet processing continues after the failed upcall, because do_execute_actions() ignores output_userspace()'s return value and later actions inherit the modified skb. Packets handled by the flow-miss drop path are intended to be dropped instead.
What does the fix change?
The fix moves skb_tx_error() to the flow-miss drop path, immediately before the skb is freed. This prevents skb_tx_error() from clearing zero-copy flags on a borrowed skb that may continue through remaining actions.