GHSA-G7MQ-RRQ4-X494
Vulnerability from github – Published: 2026-08-28 09:31 – Updated: 2026-08-29 09:30In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: oss: Serialize readq reset state with q->lock
snd_seq_oss_readq_clear() resets qlen, head, and tail without q->lock even though the normal reader and producer paths serialize the same ring state under that spinlock. A reset can therefore race snd_seq_oss_readq_free() or snd_seq_oss_readq_put_event() and leave stale records in the queue, drop freshly queued ones, or report the wrong readiness after wakeup. KCSAN reports a data race between snd_seq_oss_readq_clear() and snd_seq_oss_readq_free().
Take q->lock while clearing the ring and resetting input_time. Factor the enqueue logic into a caller-locked helper so snd_seq_oss_readq_put_timestamp() updates its suppression state under the same lock instead of racing the reset path.
The buggy scenario involves two paths, with each column showing the order within that path:
reset path: locked readq updater: 1. snd_seq_oss_reset() or 1. A reader or callback producer release reaches takes q->lock on the same queue. snd_seq_oss_readq_clear(). 2. snd_seq_oss_readq_clear() 2. The updater tests or modifies resets qlen, head, tail, qlen, head, and tail. and input_time. 3. snd_seq_oss_readq_clear() 3. The updater completes its wakes sleepers on read-modify-write sequence. q->midi_sleep. 4. Without q->lock, the reset 4. The resulting ring state drives can overlap the locked later reads and readiness. update.
KCSAN reports:
BUG: KCSAN: data-race in snd_seq_oss_readq_clear / snd_seq_oss_readq_free
write to 0xffff8881069fe608 of 4 bytes by task 120516 on cpu 0: snd_seq_oss_readq_free+0x6c/0x80 snd_seq_oss_read+0xcb/0x250 odev_read+0x38/0x60 vfs_read+0xff/0x600 ksys_read+0xb4/0x140 __x64_sys_read+0x46/0x60 do_syscall_64+0xbb/0x2f0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffff8881069fe608 of 4 bytes by task 120517 on cpu 1: snd_seq_oss_readq_clear+0x1f/0x90 snd_seq_oss_reset+0xa7/0xf0 snd_seq_oss_ioctl+0x6f6/0x7e0 odev_ioctl+0x56/0xc0 __x64_sys_ioctl+0xd1/0x120 do_syscall_64+0xbb/0x2f0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x00000001 -> 0x00000000
{
"affected": [],
"aliases": [
"CVE-2026-80628"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-28T08:16:47Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: seq: oss: Serialize readq reset state with q-\u003elock\n\nsnd_seq_oss_readq_clear() resets qlen, head, and tail without\nq-\u003elock even though the normal reader and producer paths serialize the\nsame ring state under that spinlock. A reset can therefore race\nsnd_seq_oss_readq_free() or snd_seq_oss_readq_put_event() and leave\nstale records in the queue, drop freshly queued ones, or report the\nwrong readiness after wakeup. KCSAN reports a data race between\nsnd_seq_oss_readq_clear() and snd_seq_oss_readq_free().\n\nTake q-\u003elock while clearing the ring and resetting input_time. Factor\nthe enqueue logic into a caller-locked helper so\nsnd_seq_oss_readq_put_timestamp() updates its suppression state under\nthe same lock instead of racing the reset path.\n\nThe buggy scenario involves two paths, with each column showing the\norder within that path:\n\nreset path: locked readq updater:\n1. snd_seq_oss_reset() or 1. A reader or callback producer\n release reaches takes q-\u003elock on the same queue.\n snd_seq_oss_readq_clear().\n2. snd_seq_oss_readq_clear() 2. The updater tests or modifies\n resets qlen, head, tail, qlen, head, and tail.\n and input_time.\n3. snd_seq_oss_readq_clear() 3. The updater completes its\n wakes sleepers on read-modify-write sequence.\n q-\u003emidi_sleep.\n4. Without q-\u003elock, the reset 4. The resulting ring state drives\n can overlap the locked later reads and readiness.\n update.\n\nKCSAN reports:\n\nBUG: KCSAN: data-race in snd_seq_oss_readq_clear /\nsnd_seq_oss_readq_free\n\nwrite to 0xffff8881069fe608 of 4 bytes by task 120516 on cpu 0:\n snd_seq_oss_readq_free+0x6c/0x80\n snd_seq_oss_read+0xcb/0x250\n odev_read+0x38/0x60\n vfs_read+0xff/0x600\n ksys_read+0xb4/0x140\n __x64_sys_read+0x46/0x60\n do_syscall_64+0xbb/0x2f0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nread to 0xffff8881069fe608 of 4 bytes by task 120517 on cpu 1:\n snd_seq_oss_readq_clear+0x1f/0x90\n snd_seq_oss_reset+0xa7/0xf0\n snd_seq_oss_ioctl+0x6f6/0x7e0\n odev_ioctl+0x56/0xc0\n __x64_sys_ioctl+0xd1/0x120\n do_syscall_64+0xbb/0x2f0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nvalue changed: 0x00000001 -\u003e 0x00000000",
"id": "GHSA-g7mq-rrq4-x494",
"modified": "2026-08-29T09:30:26Z",
"published": "2026-08-28T09:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80628"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/287d506d4e0865918cec82bb1361f283a08c979b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43e10709b1ba288bcbabb9b9cb6e518b2a5d8506"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49ce92d207820f588b0406add82f053decfbe5d9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.
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.