Description
In the Linux kernel, the following vulnerability has been resolved:

net: packet: fix wrong transport_header when sending VLAN-tagged frame

In packet_parse_headers(), when processing a VLAN-tagged frame,
skb_set_network_header() is called 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 the outer VLAN EtherType
(e.g. 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 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_probe_transport_header() to before skb_set_network_header(). At
the time skb_probe_transport_header() is called, network_header still
points to the VLAN header, so nhoff correctly points to the VLAN header.
The flow dissector can then parse the VLAN header, extract the inner
EtherType, and advance nhoff to the inner protocol header, allowing
transport_header to be set correctly.
Published: 2026-09-04
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Incorrect transport header processing in VLAN‑tagged frames that can lead to network stack errors or denial of service
Action: Apply Patch
AI Analysis

Impact

The bug occurs when the kernel misorders the parsing of VLAN‑tagged frames, causing the inner protocol header to be read as a VLAN header. This misinterpretation leaves the transport_header at an uninitialized value, which can disrupt subsequent packet processing and potentially cause the system to drop or mishandle traffic. The weakness reflects improper initialization of essential packet state, weakening the reliability of the network stack.

Affected Systems

All Linux kernel versions that have not incorporated the fix found in the provided patches. The vulnerability applies to generic Linux kernels, affecting any deployment that processes VLAN‑tagged frames using the legacy packet parsing routine.

Risk and Exploitability

No publicly documented exploit exists, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is unavailable, and a CVSS score is not provided. Based on the available data, the risk is low to moderate: the flaw is a kernel internal error that may only be triggered by specific VLAN traffic and can lead to denial of service rather than remote code execution. Attackers would need to manipulate network traffic to exploit the misparsing path, so the likelihood of exploitation is limited by the exposure of the vulnerable network interface.

Generated by OpenCVE AI on September 4, 2026 at 19:29 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the fix for this issue or apply the upstream patch indicated by the commit references
  • If a kernel update is not immediately possible, restrict or disable VLAN tagging on critical interfaces to prevent malformed frames from reaching the packet parsing path
  • Continuously monitor kernel logs and system stability indicators for signs of dropped or malformed packets that may suggest an underlying parsing error

Generated by OpenCVE AI on September 4, 2026 at 19:29 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4777-1 linux security update
Debian DLA Debian DLA DLA-4788-1 linux-6.12 security update
History

Fri, 04 Sep 2026 17:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: net: packet: fix wrong transport_header when sending VLAN-tagged frame In packet_parse_headers(), when processing a VLAN-tagged frame, skb_set_network_header() is called 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 the outer VLAN EtherType (e.g. 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 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_probe_transport_header() to before skb_set_network_header(). At the time skb_probe_transport_header() is called, network_header still points to the VLAN header, so nhoff correctly points to the VLAN header. The flow dissector can then parse the VLAN header, extract the inner EtherType, and advance nhoff to the inner protocol header, allowing transport_header to be set correctly.
Title net: packet: fix wrong transport_header when sending VLAN-tagged frame
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-04T17:19:16.531Z

Reserved: 2026-08-26T14:34:25.800Z

Link: CVE-2026-80906

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-04T18:18:00.240

Modified: 2026-09-04T18:18:00.240

Link: CVE-2026-80906

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-04T22:00:05Z

Weaknesses

No weakness.