From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-80971][MODERATE 7.0] ALSA: bcd2000: clear the URB pointers on disconnect Date: Fri, 11 Sep 2026 16:00:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-80971 X-AL-KERNEL-Priority: MODERATE 7.0 X-AL-KERNEL-Severity: MODERATE 7.0 X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: YES X-AL-KERNEL-ActionableScore: 5 X-AL-KERNEL-ActionableScore-Lower: 4 X-AL-KERNEL-Commit: eb482a06791d6168beb8c78cc904ac5a5ed96a55 List-Id: CVE: CVE-2026-80971 Priority: MODERATE 7.0 AL-KERNEL base severity: MODERATE KPANIC flag: YES Patch: ALSA: bcd2000: clear the URB pointers on disconnect Commit: eb482a06791d6168beb8c78cc904ac5a5ed96a55 Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=eb482a06791d6168beb8c78cc904ac5a5ed96a55 Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-80971 Analysis date: Fri, 11 Sep 2026 16:00:08 -0400 ActionableScore: 5 ActionableScore lower bound: 4 Actionable bucket: Actionable Moderate / Strong Important candidate requiring manual review Manual review required: YES Summary: No one-sentence report phrase was found. ====================================================================== ABOUT THIS REPORT ====================================================================== The original Linux kernel CVE announcement for CVE-2026-80971 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-80971 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 7.0 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-80971 MODERATE https://www.kernelcve.org/list/?q=CVE-2026-80971 CHECK WITH IMPACT FROM ORIG NN MODERATE 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-362;*CWE-672;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7';DESCR 'A use-after-free in the ALSA/USB bcd2000 driver can occur after USB disconnect because freed midi_in_urb and midi_out_urb pointers remain reachable from rawmidi and completion paths. A local user or process with access to the rawmidi device can keep a substream open while disconnect handling frees the URBs, after which the close trigger path may write to the freed output URB and submit it to the USB core. For the CVSS the PR:L is used because reliable triggering requires local code execution or a local process context with access to the exposed sound device, not full administrator privileges. The issue is not network reachable. Impact is at least local denial of service via kernel crash and in the paranoid case may include privilege escalation because the bug is a kernel heap use-after-free with a write to freed memory.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 5) YES READ DANGER USB RACE UAF HARDWARE LINUS TEST KPANIC INCREASED_TO_MODERATE7_BASED_ON_GUESSCVSS NO NO checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=5 ActionableScoreLower=4 PrimitiveClass=CLASS_B RealUAF=YES HostAdminRequired=NO NamespaceScopedPrivilege=NO ImportantCandidate=YES ManualReview=REQUIRED AutoDowngradeAllowed=NO 1. ActionableScore * Raw conservative score: 4 * Conservative score: 4 * Raw paranoid score: 5 * Paranoid score: 5 * Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**:: No floor or cap changed the score. 2. Signal breakdown Conservative positive signals: * +2 Real UAF / active lifetime violation: freed midi_out_urb and midi_in_urb pointers remain reachable after usb_free_urb(), and later rawmidi or completion paths can use them. * +1 Reliable kernel crash / strong DoS: KASAN shows slab-use-after-free in bcd2000_midi_send() and usb_submit_urb(), with realistic kernel crash potential. * +1 Local below-host-admin reachability: a local process with access to the rawmidi device can keep a substream open across disconnect and later reach the close trigger path. Paranoid additional signal: * +1 Constrained post-free write / unresolved Class B leverage: bcd2000_midi_send() writes to a freed URB field and then passes the stale URB to USB core. This is more than a read-only stale dereference, but no controlled reclaim, arbitrary write, or callback control is demonstrated. Non-awarded signals: * Strong LPE leverage +2 not awarded: controlled reclaim, attacker-shaped replacement object, arbitrary write, callback control, or credential overwrite is not established. * Structured stale-object leverage not separately awarded: the stale object is an active URB, but meaningful attacker control over replacement contents is not shown. * Concrete repeated release/refcount +1 not awarded: this is not a second put/free/refcount mutation on the same dangling reference. * Extra Availability +1 not awarded: the same crash is already counted once. * Remote reachability not awarded: this is not network-triggerable. * Physical/rare-hardware penalty not applied: the driver is hardware-specific, but the evidence establishes a real kernel heap UAF in an exposed local device path, and the prompt requires not reducing severity merely because code is in a driver. Repeated release/refcount checklist: * First release can end lifetime: yes, usb_free_urb() frees the URBs. * Exact same reference survives: yes, pointers remain in bcd2k until patch clears them. * Second operation is lifetime/refcount mutation: no, later paths write, submit, or resubmit the freed URB rather than performing a second free/put. * Concrete repeated release/refcount +1 awarded: no. * Paranoid repeated-refcount leverage +1 awarded: no. * FLOOR 5 applied: no. Paranoid score reaches 5 by arithmetic due to post-free write and unresolved Class B leverage. 3. Reachability analysis The practical attacker is a local user or local process with access to the ALSA rawmidi device. The commit describes a substream that remains open when the USB device is unplugged, then reaches bcd2000_midi_send() from the trigger path on close. This is below host-admin in typical audio-device access models, but depends on device-node permissions and local policy. Host administrator privileges are not positively required. Namespace-scoped privilege is not relevant because this is an ALSA USB device path, not a namespace capability path. Prior setup requires the affected USB MIDI device and driver to be present. A disconnect event is part of the trigger, which may involve physical device removal or equivalent device teardown. The output path after disconnect appears deterministic once the stale pointer remains reachable. The input completion/resubmit side involves async ordering, but the commit notes usb_poison_urb() is needed because usb_kill_urb() does not prevent later submission. 4. Primitive and severity interpretation The exact primitive is a kernel heap use-after-free of USB URB objects after device disconnect. The stale storage is a freed URB, which is an active structured kernel object consumed by USB core paths. The demonstrated operations include a write to midi_out_urb->transfer_buffer_length and submission of the freed URB via usb_submit_urb(). The input URB can also be exposed through completion-handler resubmission. This is stronger than an ordinary stale cleanup dereference because a post-free write to a structured kernel object is directly established. It is still Class B rather than Class A because the patch does not establish controlled reclaim, attacker-controlled replacement contents, arbitrary read/write, callback control, or demonstrated privilege escalation. Demonstrated consequence is local kernel crash / DoS. Speculative consequence is local privilege escalation if the freed URB storage can be usefully reclaimed and the fixed or limited post-free write/submission can be turned into controlled corruption. That is not proven, but the unresolved kernel heap UAF write is sufficient to prevent automatic downgrade. ImportantCandidate=YES because the bug is a confirmed kernel heap UAF with write-side stale use and unresolved exploitation leverage beyond a simple NULL dereference. AutoDowngradeAllowed=NO because automatic closure would lose a real Class B memory lifetime primitive requiring manual review. 5. One-sentence report phrase A local process with access to the ALSA bcd2000 rawmidi device can keep a substream open across USB disconnect, after which stale freed URB pointers may be written and submitted to USB core, causing a kernel UAF crash and requiring manual review for possible exploitation beyond DoS. 6. Manual review recommendation MANUAL CHECK REQUIRED Reason: confirmed kernel heap use-after-free with post-free write and USB-core submission of a stale structured object. No complete LPE primitive is demonstrated, but the issue should not be auto-closed as ordinary crash-only DoS. 7. Call-site confidence Call-site confidence: high ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: ALSA: bcd2000: clear the URB pointers on disconnect Commit: eb482a06791d6168beb8c78cc904ac5a5ed96a55 Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=eb482a06791d6168beb8c78cc904ac5a5ed96a55 Commit description: bcd2000_free_usb_related_resources() frees both URBs and leaves the pointers behind: usb_kill_urb(bcd2k->midi_out_urb); usb_kill_urb(bcd2k->midi_in_urb); usb_free_urb(bcd2k->midi_out_urb); usb_free_urb(bcd2k->midi_in_urb); The rawmidi device outlives that call. A substream that is still open when the device is unplugged reaches bcd2000_midi_send() from the trigger path on close. That function writes to the freed URB and then hands it to the USB core: bcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE; ... ret = usb_submit_urb(bcd2k->midi_out_urb, GFP_ATOMIC); usb_kill_urb() does not stop a later submission either, so a submit that races the disconnect can requeue the URB after it has been reaped. midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits it from the completion handler. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000] Write of size 4 at addr ffff00001827d388 by task bpoc/168 __asan_store4 bcd2000_midi_send [snd_bcd2000] bcd2000_midi_output_trigger [snd_bcd2000] snd_rawmidi_kernel_write1 close_substream.part.0 Freed by task 168: usb_free_urb bcd2000_disconnect [snd_bcd2000] BUG: KASAN: slab-use-after-free in usb_submit_urb Read of size 8 at addr ffff00001827d3b8 by task bpoc/168 Clear both pointers after freeing and test them on the paths that can still run. Poison the URBs before freeing them: usb_poison_urb() waits for a running completion handler and rejects any later submission, so after it returns the input path is quiesced and only the rawmidi trigger path can still reach bcd2000_midi_send(). No unpoison is needed; the URBs are freed on the next line. Discovered by XBOW, triaged by Baul Lee Fixes: b47a222 ("ALSA: MIDI driver for Behringer BCD2000 USB device") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260805013428.38204-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman Changed files: sound/usb/bcd2000/bcd2000.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=eb482a06791d6168beb8c78cc904ac5a5ed96a55 ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-80971 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-80971 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:L/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: 4 Paranoid ActionableScore: 5 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: YES Published priority for this report (same as in Subject): MODERATE 7.0 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).