Answer in brief
CVE-2026-89487 records a Unknown severity vulnerability in openvswitch: only skb_tx_error() a packet we are about to drop. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=36d5fe6a000790f56039afe26834265db0a3ad4c <6767d70cf46f65807a6a4c4406a518e6c12e36ae || >=36d5fe6a000790f56039afe26834265db0a3ad4c <e41a59fc056f63a7a1f42788913c53cc48d744aa || >=36d5fe6a000790f56039afe26834265db0a3ad4c <5d85eef222cfd28e73deed7402c100229e8b9e6e || >=36d5fe6a000790f56039afe26834265db0a3ad4c <0dbc2398fca3bb33eda963849f865ddb1b3aa05e || c5f0c0e7525443add533495e93ba8de6feab2396 || 1674b4bf3eea3cac51b70778e89f8025f7cfe695 || >=3.10.51 <3.11 || >=3.12.40 <3.13 | 6767d70cf46f65807a6a4c4406a518e6c12e36ae, e41a59fc056f63a7a1f42788913c53cc48d744aa, 5d85eef222cfd28e73deed7402c100229e8b9e6e, 0dbc2398fca3bb33eda963849f865ddb1b3aa05e, 3.11, 3.13 |
| Linux/Linuxgeneric | 3.14 | Not reported |
Published upstream
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 11, 2026
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.
Quoted source text, attributed separately from HOL analysis.