Cloudanix VulnDB

CVE-2026-80970

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in Linux USB sound handling can let someone already on the computer read leftover internal memory, which might later help them try to take more control of the machine.

Chainable
Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Information Disclosure
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Local information disclosure in the Linux kernel ALSA FCP ioctl path. fcp_ioctl_init() kmalloc()s a response buffer without clearing it, then copy_to_user()s the full buffer after a USB step-0 control transfer that can complete short or empty (URB_SHORT_NOT_OK is not set; only err < 0 is treated as failure). Unwritten kmalloc-8 through kmalloc-512 slab residue in the step-0 window (caller-chosen 1–255 bytes) is returned to userspace, including kernel pointers and other heap leftovers. The step-2 window is filled by a subsequent transfer and is not the leak surface.

Why it matters to the business

This is a local kernel memory leak, not remote code execution. It can weaken KASLR and help a follow-on local privilege-escalation chain on machines that expose ALSA USB FCP (desktops, workstations, embedded/audio appliances with compatible USB audio devices). Current likelihood is low: EPSS about 0.002 and flat over 30 days, not in CISA KEV, no ransomware use, exploit maturity none, published about 20 days ago with no named in-the-wild actors. Residual risk is highest where unprivileged users can open the FCP device node and a USB audio gadget is present.

How an attack unfolds

An attacker who already has local code execution and can open the ALSA FCP interface issues the init ioctl with large step-0/step-2 sizes. If the USB device returns a short or zero-length step-0 data stage, the kernel treats that as success and copies the uncleared heap buffer to the caller. Optionally pre-filling nearby kmalloc caches increases the chance of recovering useful pointers (kernel text or heap) from the step-0 region. The leak is used as a reconnaissance/KASLR-bypass primitive to support a separate local privilege-escalation exploit, not as a standalone remote compromise. No public in-the-wild campaigns or named APT use are reported.

How to fix it

Apply the upstream Linux kernel fix for ALSA FCP: zero the response buffer before use and fail the ioctl unless the step-0 USB control transfer returns the full requested step0_resp_size. Deploy the vendor or distro kernel that contains that change (no per-product fixed versions were supplied with this record). As a partial hardening control, enable heap zeroing on allocation (init_on_alloc=1) so uncleared kmalloc residue is less useful; this does not replace the patch. Restrict unprivileged access to ALSA/FCP device nodes and unneeded USB audio devices until kernels are updated.

How to confirm the fix worked

Confirm the running kernel includes the FCP fix (buffer zeroing plus full-length step-0 transfer check) via distro advisory, kernel changelog, or source/config review of sound/usb FCP ioctl handling. Verify init_on_alloc policy if used as interim hardening. Inventory hosts with USB audio / ALSA FCP, confirm device-node permissions do not allow untrusted local users to issue FCP ioctls, and re-test only with a patched kernel that the short step-0 path now returns an error instead of userspace data. Do not use unpatched kernels to reproduce the leak in production.

Typical attack path

  1. Gain local access on a Linux host whose kernel includes ALSA FCP and that has a compatible USB audio device
  2. Open the ALSA FCP device interface available to the attacker
  3. Invoke the FCP init ioctl with large validated step-0 and step-2 response sizes (1–255 bytes each)
  4. Rely on a short or empty USB step-0 control transfer so uninitialized kmalloc bytes remain in the kernel buffer
  5. Read the copied step-0 region in userspace to recover leftover slab contents and kernel pointers
  6. Use leaked addresses to bypass KASLR or otherwise assist a separate local privilege-escalation attempt

How to detect it

This leak does not drop files or make a distinctive network connection; post-exploitation evidence is thin. Hunt on hosts that had unpatched ALSA FCP and a USB audio device: audit logs for unprivileged processes opening sound/FCP device nodes and issuing unusual ioctls; USB telemetry for repeated class-specific interface IN control transfers on the FCP endpoint around the time of those ioctls; and crash/debug logs that mention ALSA FCP or snd_usb_ctl_msg failures. Correlate with local privilege-escalation attempts (new root processes, unexpected kernel-module loads, KASLR-sensitive probing) after such activity. Absence of these signals does not prove the leak was unused.

What your security team should do

  • Patch Linux kernels that include ALSA USB FCP as soon as vendor/distro builds containing the FCP init-buffer fix are available
  • Prioritize workstations, audio appliances, and any multi-user hosts where unprivileged users can access sound device nodes
  • Until patched, restrict FCP/ALSA device-node access and disable unused USB audio devices
  • Enable init_on_alloc as defense-in-depth, not as a substitute for the patch
  • Track this CVE as a local infoleak (low EPSS, not KEV); raise urgency if it is chained with a local LPE in your environment
  • Hunt for unusual local FCP ioctl activity rather than expecting network IOCs

The record

In the Linux kernel, the following vulnerability has been resolved: ALSA: FCP: do not copy out an uninitialised init response fcp_ioctl_init() allocates its response buffer with kmalloc() and copies the whole buffer back to userspace: buf_size = init.step0_resp_size + init.step2_resp_size; void *resp __free(kfree) = kmalloc(buf_size, GFP_KERNEL); ... if (copy_to_user(arg->resp, resp, buf_size)) return -EFAULT; Nothing clears the buffer, and the only writer of its leading step0_resp_size bytes is the step-0 control transfer: err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), FCP_USB_REQ_STEP0, USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_IN, 0, private->bInterfaceNumber, step0_resp, private->step0_resp_size); if (err < 0) return err; usb_fill_control_urb() does not set URB_SHORT_NOT_OK, so a short or zero-length data stage completes with status 0 and snd_usb_ctl_msg() returns a small actual_length. The only check is err < 0, so a short transfer is accepted as success. snd_usb_ctl_msg() copies the full size back unconditionally: buf = kmemdup(data, size, GFP_KERNEL); ... memcpy(data, buf, size); Bytes the device never wrote are therefore restored into resp unchanged and copied to userspace. step0_resp_size and step2_resp_size are each validated only to 1..255, so the caller also picks the slab cache, from kmalloc-8 up to kmalloc-512. On 7.2.0-rc5 (arm64), device answering step 0 with a zero-length data stage, s0 = s2 = 255: # init_on_alloc off, no spray step0 window [0,255): nonzero=94/255 000: 00 80 60 06 00 00 ff ff 18 00 00 00 57 01 ea 01 010: 08 78 22 13 00 00 ff ff a8 c4 5f 80 00 80 ff ff # same kernel, kmalloc-512 pre-seeded with an 8-byte tag step0 window [0,255): nonzero=219/255 tagbytes=232 # identical run, init_on_alloc=1 step0 window [0,255): nonzero=0/255 tagbytes=0 # all three runs step2 window [255,510): device words matched=62/62 a8 c4 5f 80 00 80 ff ff is the little-endian kernel text address ffff8000805fc4a8. The step-2 window is unaffected, so the disclosure is exactly the step-0 region. Zero the buffer, and require the step-0 transfer to deliver the full step0_resp_size bytes so a short data stage is reported as an error. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

Affected packages

Ecosystem Package Introduced Fixed