From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-80925][MODERATE REGULAR] vlan: fix skb_under_panic and races when toggling HW VLAN offload Date: Wed, 09 Sep 2026 13:12:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-80925 X-AL-KERNEL-Priority: MODERATE REGULAR X-AL-KERNEL-Severity: MODERATE REGULAR X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: NO X-AL-KERNEL-ActionableScore: 3 X-AL-KERNEL-ActionableScore-Lower: 2 X-AL-KERNEL-Commit: a29f3b884ba50217e6f50414f568073221e2bb07 List-Id: 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 Closes: https://lore.kernel.org/netdev/99d678ae-c7b2-4b44-b534-b8320679deb3@h-partners.com/ Cc: # 3.19: e16e960 : ipvlan: inherit needed_headroom and needed_tailroom from phy_dev Cc: # 3.19: cef5186 : macvlan: inherit needed_headroom and needed_tailroom from lowerdev Cc: # 3.19 Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260811085246.2267779-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman 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).