[CVE-2026-80925][MODERATE REGULAR] vlan: fix skb_under_panic and races when toggling HW VLAN offload

[CVE-2026-80925][MODERATE REGULAR] vlan: fix skb_under_panic and races when toggling HW VLAN offload

[AL-KERNEL]

CVE: CVE-2026-80925
Priority: MODERATE REGULAR
AL-KERNEL base severity: MODERATE
KPANIC flag: NO
Patch: vlan: fix skb_under_panic and races when toggling HW VLAN offload
Commit: a29f3b884ba50217e6f50414f568073221e2bb07
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a29f3b884ba50217e6f50414f568073221e2bb07
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-80925
Analysis date: Wed, 09 Sep 2026 13:12:32 -0400
ActionableScore: 3
ActionableScore lower bound: 2
Actionable bucket: Borderline / manual review recommended
Manual review required: YES

Summary:
No one-sentence report phrase was found.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-80925 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-80925

The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.

The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.

Published priority for this report: MODERATE REGULAR
Manual review required: YES

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2026-80925	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-80925 CHECK WITH IMPACT FROM ORIG NN LOW	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H';CWE-362;CWE-662;*CWE-787;Other CVSS 'AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '5.8';DESCR 'A race in the VLAN transmit setup can occur when hardware VLAN TX offload is toggled on the lower device while lockless TX paths read dev hard_header_len. Upper layers may reserve insufficient skb headroom from a stale or mismatched value, and vlan_dev_hard_header() can later hit skb_under_panic() when inserting the VLAN header. For the CVSS the PR:L is used for the paranoid score because CAP_NET_ADMIN or similar network administration capability may be delegated to container root or a service account rather than full host root. The issue is not directly network reachable because packet traffic alone does not toggle the device offload state. Impact is at least local denial of service via kernel panic, with limited confidentiality or integrity impact kept only for manual review sensitivity due to the headroom underflow race.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Borderline / manual review recommended (with actual score 3)  SKIP CVE-2026-80925 UNKNOWN SKIP The Fixes patch not applied yet, so unlikely that actual: url YES  NO NO unknown 	MAYBE	WARNONLY RACE SKB HARDWARE LINUS PACKET  INCREASED_FROM_LOW_BASED_ON_REQUIREMANUALCHECK DECREASED_TO_MODERATEREG_BASED_ON_ACTIONABLESCORELESSTHAN4	-	-	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=3
ActionableScoreLower=2
PrimitiveClass=CLASS_C
RealUAF=NO
HostAdminRequired=UNKNOWN
NamespaceScopedPrivilege=UNKNOWN
ImportantCandidate=NO
ManualReview=RECOMMENDED
AutoDowngradeAllowed=YES

1. ActionableScore

* Raw conservative score: 2
* Conservative score: 2
* Raw paranoid score: 3
* Paranoid score: 3
* Final recommended bucket: **Borderline / manual review recommended**::

No floor or cap changed the score.

2. Signal breakdown

Conservative signals:

* +1 Reliable kernel crash / strong DoS. The commit directly reports insufficient skb headroom leading to skb_under_panic when vlan_dev_hard_header() is called.
* +1 Memory layout invariant restoration. The patch restores consistency between hard_header_len, needed_headroom, needed_tailroom, and header_ops for VLAN devices.
* +1 Common networking packet path involvement. The race affects lockless TX paths such as packet_snd and ip6_finish_output2, not only obscure diagnostic code.
* -1 Capability-gated control-plane operation with unresolved namespace scope. Triggering requires toggling HW VLAN TX offload on the lower device, which is normally a CAP_NET_ADMIN device-management operation, but the complete namespace and host-admin boundary is not fully established.

Paranoid additional signal:

* +1 Weak memory-safety-adjacent concern. The bug is not only a passive bookkeeping error: stale hard_header_len can make upper layers reserve insufficient skb headroom before VLAN header creation. This supports manual review sensitivity, but not CLASS_A or CLASS_B scoring.

Non-awarded signals:

* RealUAF not awarded. No freed or post-lifetime object use is established.
* Controlled reclaim not demonstrated.
* Arbitrary or directed kernel write not demonstrated.
* Confidentiality and integrity impact not awarded. The demonstrated terminal behavior is skb_under_panic rather than an independently useful read or write primitive.
* Remote reachability not awarded. Packet traffic alone does not toggle HW VLAN offload.
* Race penalty not applied. The issue is a race, but the supplied evidence does not prove a narrow one-shot timing window that merits a separate negative point.
* Extra Availability not awarded. The same skb_under_panic crash is already counted once.

3. Reachability analysis

The apparent trigger requires a VLAN device and a lower device whose HW VLAN TX offload state is toggled while TX paths are active. Toggling NETIF_F_HW_VLAN_CTAG_TX or NETIF_F_HW_VLAN_STAG_TX is a control-plane network-device operation, normally requiring CAP_NET_ADMIN over the relevant device. The evidence does not fully prove whether the complete trigger must be performed with host/init namespace CAP_NET_ADMIN or whether all required stages can be done with delegated or namespace-scoped privileges. Therefore HostAdminRequired is UNKNOWN and NamespaceScopedPrivilege is UNKNOWN.

This is not directly network reachable. Remote packets may exercise the TX path after configuration changes, but the security-relevant state change is the local offload toggle, not ordinary packet delivery. No special rare hardware penalty is applied because VLAN offload is a normal NIC feature class, but no broad default exposure bonus beyond common TX path involvement is used.

4. Primitive and severity interpretation

The exact primitive is an inconsistent VLAN transmit header/headroom state caused by dynamically changing vlandev->hard_header_len while lockless TX paths read it. This can result in insufficient skb headroom and skb_under_panic during VLAN header insertion.

This is not an active structured UAF, not fixed stale storage UAF, and not a concrete repeated release/refcount case. It is best classified as CLASS_C: crash/DoS behavior with a memory-layout invariant violation but without a demonstrated independently useful corruption primitive.

Demonstrated consequence is local kernel crash / DoS. Speculative consequences beyond DoS are not strong enough for ImportantCandidate because the panic check is the observed failure mode and no post-panic attacker-controlled write, reclaim, disclosure, or privilege-escalation primitive is established. AutoDowngradeAllowed is YES because this is not CLASS_A or strong CLASS_B, although manual review is recommended due to the networking TX race and headroom-underflow context.

5. One-sentence report phrase

A VLAN TX race can leave upper layers using stale hard_header_len information after HW VLAN offload changes, causing insufficient skb headroom and skb_under_panic, with impact limited to local DoS unless further memory corruption evidence is found.

6. Manual review recommendation

MANUAL CHECK RECOMMENDED

Reason: the demonstrated impact is crash-only, but the bug is in the networking TX path and involves skb headroom invariants, so it should not be treated as a trivial warning-only issue without review.

7. Call-site confidence

Call-site confidence: high

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: vlan: fix skb_under_panic and races when toggling HW VLAN offload
Commit: a29f3b884ba50217e6f50414f568073221e2bb07
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a29f3b884ba50217e6f50414f568073221e2bb07

Commit description:

Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or
NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(),
which dynamically changed vlandev->hard_header_len.

This causes two issues:
1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2)
   read dev->hard_header_len without holding RTNL lock. Mutating
   hard_header_len dynamically under RTNL creates a data race where upper
   layers reserve insufficient headroom based on a stale hard_header_len,
   resulting in skb_under_panic when vlan_dev_hard_header() is called.
2. In addition, vlan_transfer_features() updated hard_header_len without
   updating header_ops, causing a mismatch between allocated headroom
   and header creation.

Always setting dev->hard_header_len = real_dev->hard_header_len and
dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN unconditionally
ensures:
- dev->hard_header_len remains 100% static and immutable at real_dev->hard_header_len,
  eliminating all dynamic runtime updates and data races on hard_header_len.
- Upper layers allocating skbs via LL_RESERVED_SPACE() will always reserve
  sufficient headroom for software VLAN tag insertion (real_dev->hard_header_len +
  real_dev->needed_headroom + VLAN_HLEN).
- vlandev inherits real_dev->needed_tailroom so underlying trailer/padding/ICV
  requirements are honored.
- AF_PACKET SOCK_RAW network header offsets remain correctly aligned at
  real_dev->hard_header_len.
- vlan_header_ops is used unconditionally.

Note to stable teams: Make sure to backport these commits:

e16e960 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev")
cef5186 ("macvlan: inherit needed_headroom and needed_tailroom from lowerdev")

Fixes: 1da177e ("Linux-2.6.12-rc2")
Reported-by: Tangxin Xie <xietangxin@h-partners.com>
Closes: https://lore.kernel.org/netdev/99d678ae-c7b2-4b44-b534-b8320679deb3@h-partners.com/
Cc: <stable@vger.kernel.org> # 3.19: e16e960 : ipvlan: inherit needed_headroom and needed_tailroom from phy_dev
Cc: <stable@vger.kernel.org> # 3.19: cef5186 : macvlan: inherit needed_headroom and needed_tailroom from lowerdev
Cc: <stable@vger.kernel.org> # 3.19
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260811085246.2267779-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Changed files:
  net/8021q/vlan_dev.c

Diff excerpt:

Not included in this email. See the upstream URL for the full patch.

Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a29f3b884ba50217e6f50414f568073221e2bb07

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-80925 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-80925

The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.

The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.

The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.

Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:

  Conservative CVSS vector: AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
  The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
  The Best / paranoid CVSS score: 5.8

The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.

CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.

A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.

  Conservative ActionableScore: 2
  Paranoid ActionableScore: 3

The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.

For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:

  ActionableScore below 5   -> MODERATE REGULAR
  ActionableScore 5 or more -> MODERATE 7.0

The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.

There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).

KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.

AL-KERNEL base severity for this report: MODERATE
KPANIC detected for this report: NO
Published priority for this report (same as in Subject): MODERATE REGULAR

These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).

Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is alexanjelausa@gmail.com (and both
send reply to CVE record itself too and see "reply" button below for howto reply).