CVE-2026-90049

The Linux kernel's skb_zerocopy() helper destructively calls skb_tx_error() on the source socket buffer when skb_orphan_frags() fails, completing the source skb's zerocopy uarg and clearing the SKBFL_SHARED_FRAG page-ownership flag on a buffer the helper does not own. On the Open vSwitch OVS_ACTION_ATTR_USERSPACE path the skb is not freed after this error - do_execute_actions() ignores output_userspace()'s return value and keeps forwarding the same skb - so zerocopy buffers can be signaled as free while still in flight, and because SKBFL_SHARED_FRAG is cleared, esp_input() can decrypt in place over page fragments the skb does not privately own. A local attacker able to push traffic through an affected Open vSwitch datapath or an nfnetlink_queue (NFQUEUE) flow and trigger a frag-orphaning failure can cause use-after-free conditions and kernel memory/data corruption, with kernel-level confidentiality, integrity and availability impact (CVSS 9.3, local vector, scope changed). Any Linux system with the pre-fix kernel code is affected, with realistic trigger exposure on hosts running the Open vSwitch kernel datapath or NFQUEUE userspace queuing; the source data provides no specific vulnerable or fixed version numbers. No exploitation is known, no public proof-of-concept exists, and the issue is not listed in CISA KEV.

What to do: Apply the stable fix ('net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy()') as soon as your distribution or vendor ships an updated kernel, prioritizing hypervisors, SDN gateways and other hosts running the Open vSwitch kernel module or NFQUEUE/nfnetlink_queue rules (check with 'lsmod | grep openvswitch' and nftables/iptables NFQUEUE targets). Until patched, limit untrusted local code execution on OVS/NFQUEUE hosts and treat IPsec/ESP termination on those hosts as higher risk. No public PoC or in-the-wild exploitation is known, so monitor vendor advisories for fixed version numbers.