GHSA-HGW4-F68W-CXG8
Vulnerability from github – Published: 2026-10-06 09:31 – Updated: 2026-10-06 09:31In the Linux kernel, the following vulnerability has been resolved:
ALSA: 6fire: fix OOB write from device-reported iso length
usb6fire_pcm_in_urb_handler() sizes each outgoing isochronous packet as (actual_length - 4) / (in_n_analog << 2) * (out_n_analog << 2) + 4, where actual_length is the unsigned length the device reported for the matching IN packet. A packet completed with status 0 and actual_length < 4 wraps the subtraction to 0x7fffffec; a zero-length isochronous packet is legal on the bus, and the preceding loop rejects only non-zero status. The sum reaches memset() on out_urb->buffer, a 4832-byte object from kcalloc(PCM_MAX_PACKET_SIZE, PCM_N_PACKETS_PER_URB).
Even without the wrap the result is out of bounds: at 88.2/96 kHz the 4-in/6-out scaling turns a full 420-byte IN packet into 628, so eight packets span 5024 bytes of that buffer. usb_submit_urb() rejects an over-long descriptor only after the memset() and the usb6fire_pcm_playback() copy of user PCM data have run.
Guard the subtraction as the sibling usb6fire_pcm_capture() already does, and limit the frame count to what fits in rt->out_packet_size, the OUT endpoint's wMaxPacketSize. This bounds total_length by the buffer size while keeping each packet length aligned to a whole output frame.
BUG: KASAN: out-of-bounds in usb6fire_pcm_in_urb_handler (sound/usb/6fire/pcm.c:338) Write of size 18446744073709551456 at addr ffff88802a3d0000 by task vhci_rx/5018 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) kasan_check_range (mm/kasan/generic.c:186 mm/kasan/generic.c:200) __asan_memset (mm/kasan/shadow.c:84) usb6fire_pcm_in_urb_handler (sound/usb/6fire/pcm.c:338) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1741) vhci_rx_loop (drivers/usb/usbip/vhci_rx.c:107 drivers/usb/usbip/vhci_rx.c:242) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
Allocated by task 10: __kmalloc_cache_noprof (mm/slub.c:5563) usb6fire_pcm_init (sound/usb/6fire/pcm.c:560 sound/usb/6fire/pcm.c:595) usb6fire_chip_probe (sound/usb/6fire/chip.c:133) usb_probe_interface (drivers/usb/core/driver.c:399)
The buggy address belongs to the object at ffff88802a3d0000 which belongs to the cache kmalloc-8k of size 8192 The buggy address is located 0 bytes inside of 4832-byte region [ffff88802a3d0000, ffff88802a3d12e0) Kernel panic - not syncing: Fatal exception in interrupt
{
"affected": [],
"aliases": [
"CVE-2026-98312"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-06T09:18:22Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: 6fire: fix OOB write from device-reported iso length\n\nusb6fire_pcm_in_urb_handler() sizes each outgoing isochronous packet as\n(actual_length - 4) / (in_n_analog \u003c\u003c 2) * (out_n_analog \u003c\u003c 2) + 4, where\nactual_length is the unsigned length the device reported for the matching\nIN packet. A packet completed with status 0 and actual_length \u003c 4 wraps\nthe subtraction to 0x7fffffec; a zero-length isochronous packet is legal\non the bus, and the preceding loop rejects only non-zero status. The sum\nreaches memset() on out_urb-\u003ebuffer, a 4832-byte object from\nkcalloc(PCM_MAX_PACKET_SIZE, PCM_N_PACKETS_PER_URB).\n\nEven without the wrap the result is out of bounds: at 88.2/96 kHz the\n4-in/6-out scaling turns a full 420-byte IN packet into 628, so eight\npackets span 5024 bytes of that buffer. usb_submit_urb() rejects an\nover-long descriptor only after the memset() and the\nusb6fire_pcm_playback() copy of user PCM data have run.\n\nGuard the subtraction as the sibling usb6fire_pcm_capture() already does,\nand limit the frame count to what fits in rt-\u003eout_packet_size, the OUT\nendpoint\u0027s wMaxPacketSize. This bounds total_length by the buffer size\nwhile keeping each packet length aligned to a whole output frame.\n\n BUG: KASAN: out-of-bounds in usb6fire_pcm_in_urb_handler (sound/usb/6fire/pcm.c:338)\n Write of size 18446744073709551456 at addr ffff88802a3d0000 by task vhci_rx/5018\n Call Trace:\n dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)\n print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)\n kasan_report (mm/kasan/report.c:595)\n kasan_check_range (mm/kasan/generic.c:186 mm/kasan/generic.c:200)\n __asan_memset (mm/kasan/shadow.c:84)\n usb6fire_pcm_in_urb_handler (sound/usb/6fire/pcm.c:338)\n __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657)\n usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1741)\n vhci_rx_loop (drivers/usb/usbip/vhci_rx.c:107 drivers/usb/usbip/vhci_rx.c:242)\n kthread (kernel/kthread.c:436)\n ret_from_fork (arch/x86/kernel/process.c:158)\n ret_from_fork_asm (arch/x86/entry/entry_64.S:245)\n\n Allocated by task 10:\n __kmalloc_cache_noprof (mm/slub.c:5563)\n usb6fire_pcm_init (sound/usb/6fire/pcm.c:560 sound/usb/6fire/pcm.c:595)\n usb6fire_chip_probe (sound/usb/6fire/chip.c:133)\n usb_probe_interface (drivers/usb/core/driver.c:399)\n\n The buggy address belongs to the object at ffff88802a3d0000\n which belongs to the cache kmalloc-8k of size 8192\n The buggy address is located 0 bytes inside of\n 4832-byte region [ffff88802a3d0000, ffff88802a3d12e0)\n Kernel panic - not syncing: Fatal exception in interrupt",
"id": "GHSA-hgw4-f68w-cxg8",
"modified": "2026-10-06T09:31:34Z",
"published": "2026-10-06T09:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98312"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/001ba7c1d9677225a5ecbc3e60d4865c08bb21d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1589afe2d099d3e817873bc474676968d7080410"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/246de677552fe5dede293a1543b632e9853f31e4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/61e665fb48e9eee44ec6d610514af383b1802cc1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cdc31537012bc7a58c95c6750db321b69dd802bb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea11ade10583cc45af515d6b24510dbfa0184ca6"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.