PT-2026-90203 · Linux · Linux
CVE-2026-89487
·
Published
2026-09-11
·
Updated
2026-09-11
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: only skb tx error() a packet we are about to drop
queue userspace packet() borrows the packet skb -- it only copies it into
a private netlink message (user skb) and does not own it; on return
do execute actions() keeps forwarding it through the flow's remaining
actions. Its error path nevertheless calls skb tx error(skb), which via
skb zcopy clear() does skb shinfo(skb)->flags &= ~SKBFL ALL ZEROCOPY,
stripping SKBFL SHARED FRAG from that live skb (skb tx error()'s kerneldoc
says "skb must be freed afterwards").
For a MSG ZEROCOPY skb carrying page-cache frags, SKBFL SHARED FRAG is
what makes esp input() skb cow data() 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).
do execute actions() ignores output userspace()'s return value, so any
action after a failed USERSPACE upcall inherits the stripped skb.
Move the skb tx error() to the flow-miss drop path - the "default"
branch of ovs dp process packet()'s switch(error), before kfree skb().
The call has been here since commit 36d5fe6a0007 ("core, nfqueue,
openvswitch: Orphan frags in skb zerocopy and handle errors") but was
harmless until esp input() began relying on SKBFL SHARED FRAG to gate
in-place decrypt; only then did stripping it on a still-forwarded skb
become a page-cache write primitive.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux