high CVSS 7.8 Actively exploited

CVE-2024-53197·Kernel vulnerability

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usb_get_configuration for allocating dev->config. This can lead to out-of-bounds accesses later, e.g. in usb_destroy_configuration.

Severity
high
Software
Kernel
Fixed in
6.12.2
Published
2024-12-27

Affected versions

From: 6.12

Until: 6.12.2

Fixed in: 6.12.2

How to fix this CVE

Update the Linux kernel to a patched version. If USB audio devices are not used on the server, blacklist the snd-usb-audio module. Restrict physical USB access and use USBGuard to whitelist authorized devices.

sudo apt update && sudo apt install --only-upgrade linux-image-generic
sudo reboot
# Disable USB audio if not needed:
echo 'blacklist snd-usb-audio' | sudo tee /etc/modprobe.d/blacklist-usb-audio.conf
sudo update-initramfs -u

Defensia detects this vulnerability

What an exploitation attempt looks like

Sample log line indicative of exploitation attempts:

Physical access attack via malicious USB audio device. The attacker connects a crafted USB device identifying as an Extigy or Mbox audio interface with a bogus bNumConfigurations value. The kernel's USB audio driver trusts this value for array indexing, causing an out-of-bounds read/write in the configuration parsing code.

WAF mitigation (if patching is not yet possible)

Add this rule to your WAF to block exploitation attempts while you schedule the patch. 

WAF cannot mitigate physical USB attacks. Compensating controls:
- Blacklist snd-usb-audio on servers that do not need USB audio
- Deploy USBGuard with a whitelist policy
- Disable USB ports in BIOS/UEFI on headless servers
- Restrict physical access to server hardware
- Enable kernel lockdown mode where supported

How to check if you are affected

  1. Check if snd-usb-audio module is loaded: lsmod | grep snd_usb_audio
  2. Check kernel version against distribution security advisories
  3. Monitor USB device events: dmesg | grep -i 'usb.*audio\|extigy\|mbox'
  4. Check for USBGuard: systemctl status usbguard
  5. List connected USB devices: lsusb -v 2>/dev/null | grep -B5 -A5 'Audio'
  6. Verify USB authorization policy: cat /sys/bus/usb/devices/*/authorized

Indicators of compromise

  • USB audio devices appearing with unusual bNumConfigurations values in dmesg
  • Kernel oops or KASAN reports in snd-usb-audio or usb_audio_probe
  • Unexpected snd-usb-audio module loads on headless servers
  • Physical access events correlated with kernel crashes

FAQ

Are headless servers at risk?

Only if an attacker can physically connect a USB device. Headless servers in locked data centers have minimal risk. However, servers with USB ports exposed (colocation, edge deployments) or USB-over-IP setups could be targeted.

Can this be exploited remotely?

No. Physical USB access is required to connect the malicious device. Remote exploitation is not possible unless USB-over-IP or similar technology exposes USB ports to the network.

Does this affect virtual machines?

Only if USB passthrough is configured from host to guest. Standard virtualized environments without USB device passthrough are not affected.

Why are Extigy and Mbox specifically mentioned?

The vulnerable code has special handling for these specific USB audio devices (SB Extigy and Digidesign Mbox). The special parsing code for these devices does not validate the bNumConfigurations field, while generic USB audio device handling is not affected.

Should I blacklist snd-usb-audio on all servers?

Yes, for servers that do not use USB audio devices. This eliminates the entire attack surface. Almost no server workload requires USB audio.

Related Kernel CVEs

CVE-2021-47274CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: tracing: Correct the length check which causes memory corruption We've suffered from severe kernel crashes due to memory corruption on our production environment, like, Call Trace: [1640542.554277] general protection fault: 0000 [#1] SMP PTI [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G [1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190 [1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286 [1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX: 0000000006e931bf [1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI: ffff9a45ff004300 [1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09: 0000000000000000 [1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff9a20608d [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15: 696c662f65636976 [1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000) knlGS:0000000000000000 [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4: 00000000003606e0 [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1640542.566742] Call Trace: [1640542.567009] anon_vma_clone+0x5d/0x170 [1640542.567417] __split_vma+0x91/0x1a0 [1640542.567777] do_munmap+0x2c6/0x320 [1640542.568128] vm_munmap+0x54/0x70 [1640542.569990] __x64_sys_munmap+0x22/0x30 [1640542.572005] do_syscall_64+0x5b/0x1b0 [1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1640542.575642] RIP: 0033:0x7f45d6e61e27 James Wang has reproduced it stably on the latest 4.19 LTS. After some debugging, we finally proved that it's due to ftrace buffer out-of-bound access using a debug tool as follows: [ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000 [ 86.780806] no_context+0xdf/0x3c0 [ 86.784327] __do_page_fault+0x252/0x470 [ 86.788367] do_page_fault+0x32/0x140 [ 86.792145] page_fault+0x1e/0x30 [ 86.795576] strncpy_from_unsafe+0x66/0xb0 [ 86.799789] fetch_memory_string+0x25/0x40 [ 86.804002] fetch_deref_string+0x51/0x60 [ 86.808134] kprobe_trace_func+0x32d/0x3a0 [ 86.812347] kprobe_dispatcher+0x45/0x50 [ 86.816385] kprobe_ftrace_handler+0x90/0xf0 [ 86.820779] ftrace_ops_assist_func+0xa1/0x140 [ 86.825340] 0xffffffffc00750bf [ 86.828603] do_sys_open+0x5/0x1f0 [ 86.832124] do_syscall_64+0x5b/0x1b0 [ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9 commit b220c049d519 ("tracing: Check length before giving out the filter buffer") adds length check to protect trace data overflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent overflow entirely, the length check should also take the sizeof entry->array[0] into account, since this array[0] is filled the length of trace data and occupy addtional space and risk overflow.
CVE-2021-47378CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: destroy cm id before destroy qp to avoid use after free We should always destroy cm_id before destroy qp to avoid to get cma event after qp was destroyed, which may lead to use after free. In RDMA connection establishment error flow, don't destroy qp in cm event handler.Just report cm_error to upper level, qp will be destroy in nvme_rdma_alloc_queue() after destroy cm id.
CVE-2021-47548CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() The if statement: if (port >= DSAF_GE_NUM) return; limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off; because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6). To fix this possible array overflow, we first check port and if it is greater than or equal to DSAF_MAX_PORT_NUM, the function returns.
CVE-2024-9194CVSS 9.8Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Linux and Microsoft Windows Octopus Server on Windows, Linux allows SQL Injection.This issue affects Octopus Server: from 2024.1.0 before 2024.1.13038, from 2024.2.0 before 2024.2.9482, from 2024.3.0 before 2024.3.12766.
CVE-2024-0132CVSS 9NVIDIA Container Toolkit 1.16.1 or earlier contains a Time-of-check Time-of-Use (TOCTOU) vulnerability when used with default configuration where a specifically crafted container image may gain access to the host file system. This does not impact use cases where CDI is used. A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.

References

Track CVEs across your fleet automatically

Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2024-53197. Free for 1 server.

Get started free