From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-97574][MODERATE REGULAR] bnxt_en: Don't free the live ring's TPA state on queue restart failure Date: Fri, 25 Sep 2026 08:52:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-97574 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: unknown X-AL-KERNEL-Commit: 8ade95619cbfd1fc57f0f1a9a5ebdca2345a8d27 List-Id: CVE: CVE-2026-97574 Priority: MODERATE REGULAR AL-KERNEL base severity: MODERATE KPANIC flag: NO Patch: bnxt_en: Don't free the live ring's TPA state on queue restart failure Commit: 8ade95619cbfd1fc57f0f1a9a5ebdca2345a8d27 Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8ade95619cbfd1fc57f0f1a9a5ebdca2345a8d27 Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-97574 Analysis date: Fri, 25 Sep 2026 08:52:03 -0400 ActionableScore: 3 ActionableScore lower bound: unknown 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-97574 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-97574 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-97574 MODERATE https://www.kernelcve.org/list/?q=CVE-2026-97574 CHECK WITH IMPACT FROM ORIG NN IMPORTANT Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H';*CWE-416;*CWE-664;CWE-825;Other CVSS 'AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7';DESCR 'A use after free can occur in the bnxt_en driver when a queue restart fails after bnxt_queue_mem_alloc shallow copies a live RX ring into a clone. The clone can retain pointers to the live rings TPA state, and error cleanup can free that live state while it is still reachable by the active receive path. Later use of the freed TPA state may cause a kernel crash and may allow memory corruption impact. For the CVSS the PR:L paranoid rating is used because a reduced capability local user or service account may be able to influence network device state or memory pressure in some deployments without full host administration. The issue is not directly network reachable based on the patch. Impact is at least local denial of service and in the worst case may affect confidentiality and integrity due to the explicit use after free primitive. YES REQUIRES MANUAL CHECK';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Borderline / manual review recommended (with actual score 3) YES REMOTE UAF NETWORK DECREASED_TO_MODERATE70_BASED_ON_ACTIONABLESCORELOWERTHAN5 DECREASED_TO_MODERATEREG_BASED_ON_ACTIONABLESCORELESSTHAN4 YES NO checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=3 PrimitiveClass=CLASS_B RealUAF=YES HostAdminRequired=UNKNOWN NamespaceScopedPrivilege=UNKNOWN ImportantCandidate=NO ManualReview=RECOMMENDED AutoDowngradeAllowed=YES 1. ActionableScore * Raw conservative score: 3 * Conservative score: 3 * Raw paranoid score: 3 * Paranoid score: 3 * Final recommended bucket: **Borderline / manual review recommended**:: No UAF floor was applied. The supplied patch establishes a concrete lifetime violation, but the available evidence describes a constrained driver error-cleanup path involving fixed live RX ring TPA allocations. It does not establish attacker-controlled reclaim, replacement, field control, or a second lifetime mutation through the same dangling reference. 2. Signal breakdown * +2 Real UAF or active lifetime violation. `bnxt_queue_mem_alloc()` shallow-copies pointers from the live RX ring into a clone. An allocation failure can reach `err_free_tpa_info`, freeing `rx_tpa` and `rx_tpa_idx_map` that still belong to and are used by the live ring. * +1 Reliable kernel crash or strong DoS. Later use of the freed live RX ring TPA state can plausibly cause a kernel fault, memory-safety failure, or networking disruption. Non-awarded material signals: * +0 Controlled reclaim or controlled object replacement is not demonstrated. * +0 Arbitrary or directed kernel write is not demonstrated. * +0 Remote reachability is not established. The bug is in a network driver, but the supplied evidence does not show that remote packets alone can force queue restart and the required allocation failure. * +0 Local unprivileged trigger is not established. The complete queue-restart and allocation-failure trigger path is not visible. * +0 Structured stale-object exploitation leverage is not awarded. The freed objects are active RX ring TPA allocations, but no evidence shows attacker-influenced post-free contents, callback use, pointer traversal, or meaningful structured processing after reuse. * +0 Weak LPE concern is not awarded merely because the bug is a UAF. * +0 Concrete repeated release or refcount mutation is not established. The patch shows one erroneous free of live-ring-owned allocations, not a first release followed by a second `put`, `free`, or refcount operation on the same dangling reference. * +0 Additional Availability impact is not awarded because it would double-count the same potential kernel crash. * +0 Confidentiality and Integrity impact are not awarded. A UAF can theoretically lead to broader corruption, but no disclosure, attacker-directed write, protected-state modification, or privilege-escalation primitive is established. 3. Reachability analysis The vulnerable sequence requires a queue restart that invokes `bnxt_queue_mem_alloc()` and then encounters a later allocation failure. The clone inherits live-ring TPA pointers through `memcpy()`, and cleanup can free memory owned by the active ring. The supplied patch does not identify the exact caller initiating the queue restart, whether it can be induced by ordinary traffic, whether it requires ethtool or rtnetlink administrative operations, or whether device recovery can reach the path without an administrative actor. Therefore, HostAdminRequired is `UNKNOWN`. The supplied material also does not establish that all required queue-restart operations and affected device state are available through an attacker-controlled network namespace. NamespaceScopedPrivilege is `UNKNOWN`. No special rare hardware requirement is established beyond use of a Broadcom bnxt_en-supported NIC. The issue is driver-specific, but no hardware-only penalty is applied because no evidence shows that the affected hardware is unusually rare or physically attacker-controlled. The allocation-failure condition is an error-path prerequisite, but it is not treated as a hard race or as a negative score because the patch does not establish narrow, externally uncontrollable timing. 4. Primitive and severity interpretation The exact primitive is a real use-after-free. A cloned RX ring retains aliases to `rx_tpa` and `rx_tpa_idx_map` owned by the live RX ring. Error cleanup for the clone can free those allocations while the live receive ring continues to use them. This is closer to fixed driver-owned stale storage than to an attacker-controlled active-object replacement scenario. The affected TPA state belongs to a live ring and can be consumed by receive processing, but the supplied patch does not show which fields are later accessed or whether an attacker can control replacement memory or post-free contents. This is not a concrete repeated-release/refcount case. The evidence shows: A. An erroneous cleanup free through cloned pointers aliases live-ring memory. It does not show: B. A first lifetime operation that leaves the exact reference reachable followed by a second concrete `put`, `free`, or refcount mutation on that same dangling reference. The primitive is therefore `CLASS_B`, not `CLASS_A`. The demonstrated practical consequence is kernel instability or denial of service through later use of freed RX ring state. Memory corruption beyond the crash is possible in the general UAF sense, but no exploit-relevant reuse, arbitrary write, callback control, data disclosure, or privilege escalation mechanism is supported by the supplied evidence. ImportantCandidate is `NO` because the patch alone shows a constrained error-cleanup UAF without meaningful demonstrated exploitation leverage beyond the lifetime violation and potential crash. AutoDowngradeAllowed is `YES` because controlled reclaim, repeated lifetime mutation, security-boundary impact, and attacker-controlled post-free state remain unestablished. This should still receive manual review because the bug is a genuine kernel UAF in active network-driver state. 5. One-sentence report phrase A bnxt_en queue restart allocation failure can free TPA state still owned and used by the live RX ring due to shallow copied clone pointers, causing a kernel use-after-free and potential denial of service. 6. Manual review recommendation MANUAL CHECK RECOMMENDED The patch establishes a real UAF, but manual inspection of queue-restart callers and later live-ring TPA-state consumers is needed to determine whether unprivileged, remote, or namespace-scoped triggering and meaningful post-free reuse are possible. 7. Call-site confidence Call-site confidence: medium ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: bnxt_en: Don't free the live ring's TPA state on queue restart failure Commit: 8ade95619cbfd1fc57f0f1a9a5ebdca2345a8d27 Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8ade95619cbfd1fc57f0f1a9a5ebdca2345a8d27 Commit description: bnxt_queue_mem_alloc() shallow copies the live RX ring into the clone: memcpy(clone, rxr, sizeof(*rxr)); the code currently clears pointers that the clone owns (such as rx_agg_bmap), but rx_tpa and rx_tpa_idx_map are left pointing at memory of the live ring that was cloned. If an allocation failure happens later and the err_free_tpa_info label is taken, the live ring's memory can be freed while still in use. Fix this by initializing the clone's pointers to NULL to prevent live ring state from being freed inadvertently. Fixes: bd649c5 ("bnxt_en: handle tpa_info in queue API implementation") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260828190900.1767611-1-joe%40dama.to Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-3-joe@dama.to Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman Changed files: drivers/net/ethernet/broadcom/bnxt/bnxt.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=8ade95619cbfd1fc57f0f1a9a5ebdca2345a8d27 ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-97574 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-97574 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:L/I:L/A:H The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H The Best / paranoid CVSS score: 7 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: unknown 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).