Skip to content
CVE Ledger
  • Newest CVEsPage
  • Recently added to KEVPage
  • Rising exploitation (EPSS)Page
  • Weekly digestPage
  • StatisticsPage
  • WatchlistPage
  • API docsPage
  • MCP serverPage
  • AboutPage
  • Data sourcesPage
  • Data statusPage
  • ChangelogPage
  • How it's builtPage
  • Support the projectPage

14 results

Back

CVE-2026-80905net: tap: fix wrong transport_header when sending VLAN-tagged frame

Description

In the Linux kernel, the following vulnerability has been resolved: net: tap: fix wrong transport_header when sending VLAN-tagged frame In tap_get_user_xdp(), when processing a VLAN-tagged frame (e.g. ETH_P_8021Q), skb_set_network_header() is called first to advance network_header past the VLAN tag to the inner protocol header. skb_probe_transport_header() is then called with skb->protocol still set to ETH_P_8021Q, while nhoff (derived from skb_network_offset()) already points past the VLAN tag to the inner protocol header. In __skb_flow_dissect(), proto is initialized to ETH_P_8021Q and nhoff points past the VLAN tag. When the dissector hits case ETH_P_8021Q, it reads a struct vlan_hdr at the current nhoff via __skb_header_pointer(), but that offset contains the inner protocol header (e.g. an IP header). The bytes are misinterpreted as a VLAN header, yielding a garbage encapsulated EtherType that matches no known protocol. The dissector returns false, so skb_probe_transport_header() never calls skb_set_transport_header(), leaving transport_header at its uninitialized sentinel value (~0U). Move skb_set_network_header() to after skb_probe_transport_header(). At the time skb_probe_transport_header() is called, network_header still points to the VLAN header (offset ETH_HLEN), so nhoff is correct and the flow dissector can parse the VLAN header, extract the inner EtherType, and advance nhoff to the inner protocol header, allowing transport_header to be set correctly.

Timeline

  1. ID reserved

    By Linux

  2. · 9 days later

    Published

  3. · 56 days later

    Record updated

Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.

Scores

No CVSS score yet: neither the CNA, CISA nor NVD has scored this CVE. NVD status: Received.

EPSS (exploitation in 30 days)
0.20% · top 90% of all CVEs (13 Nov 2026)
Loading the EPSS history…

The list uses the assigner's score when there is one, then CISA's, then NVD's: Not scored.

Affected products

  • Linux · Linux

    • affected 8c76e77f9069f10505c08e02646c3ee11ad79038 – < a8f49e83e4447b885376e6a937d62df883cc8824
    • affected 8c76e77f9069f10505c08e02646c3ee11ad79038 – < c0376820922d255ae1d103c32345a6ec4c3266f7
    • affected 8c76e77f9069f10505c08e02646c3ee11ad79038 – < f1d297cad5c1eacd9fadfd0346ad97405ffbf97c
    • affected 8c76e77f9069f10505c08e02646c3ee11ad79038 – < 5ffaa5d7f56ab24a8e23cf131eadfef31a3bbc4b
    • affected 8c76e77f9069f10505c08e02646c3ee11ad79038 – < 88b79ac89ecc04d7f2613f7e1c0b46f0c4ddb2f3
    • affected 8c76e77f9069f10505c08e02646c3ee11ad79038 – < cbb35cbe8db268fefe34c23df15348cf99025298
    • affected 3cae5ef1f37a475faf7c40bc6a3c170779f3e0b1
    • affected 4.20.1 – < 4.21
  • Linux · Linux

    • affected 5.0
    • unaffected < 5.0
    • unaffected 6.1.191 – ≤ 6.1.*
    • unaffected 6.6.160 – ≤ 6.6.*
    • unaffected 6.12.114 – ≤ 6.12.*
    • unaffected 6.18.46 – ≤ 6.18.*
    • unaffected 7.1.10 – ≤ 7.1.*
    • unaffected 7.2 – ≤ *

References

References6

Sources

The same CVE in the primary databases and aggregators, to check against.

Badge for a README or a ticket

CVE-2026-80905 badge
[![CVE-2026-80905](https://cveledger.app/badge/CVE-2026-80905.svg)](https://cveledger.app/cve/CVE-2026-80905)

Record last updated .