GHSA-VV6Q-P28J-9W24
Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-23 21:30In the Linux kernel, the following vulnerability has been resolved:
null_blk: fix poll request timeout handling
When doing io_uring benchmark on /dev/nullb0, it's easy to crash the kernel if poll requests timeout triggered, as reported by David. [1]
BUG: kernel NULL pointer dereference, address: 0000000000000008 Workqueue: kblockd blk_mq_timeout_work RIP: 0010:null_timeout_rq+0x4e/0x91 Call Trace: ? null_timeout_rq+0x4e/0x91 blk_mq_handle_expired+0x31/0x4b bt_iter+0x68/0x84 ? bt_tags_iter+0x81/0x81 __sbitmap_for_each_set.constprop.0+0xb0/0xf2 ? __blk_mq_complete_request_remote+0xf/0xf bt_for_each+0x46/0x64 ? __blk_mq_complete_request_remote+0xf/0xf ? percpu_ref_get_many+0xc/0x2a blk_mq_queue_tag_busy_iter+0x14d/0x18e blk_mq_timeout_work+0x95/0x127 process_one_work+0x185/0x263 worker_thread+0x1b5/0x227
This is indeed a race problem between null_timeout_rq() and null_poll().
null_poll() null_timeout_rq() spin_lock(&nq->poll_lock) list_splice_init(&nq->poll_list, &list) spin_unlock(&nq->poll_lock)
while (!list_empty(&list)) req = list_first_entry() list_del_init() ... blk_mq_add_to_batch() // req->rq_next = NULL spin_lock(&nq->poll_lock)
// rq->queuelist->next == NULL
list_del_init(&rq->queuelist)
spin_unlock(&nq->poll_lock)
Fix these problems by setting requests state to MQ_RQ_COMPLETE under nq->poll_lock protection, in which null_timeout_rq() can safely detect this race and early return.
Note this patch just fix the kernel panic when request timeout happen.
[1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/
{
"affected": [],
"aliases": [
"CVE-2023-53531"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T12:15:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnull_blk: fix poll request timeout handling\n\nWhen doing io_uring benchmark on /dev/nullb0, it\u0027s easy to crash the\nkernel if poll requests timeout triggered, as reported by David. [1]\n\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nWorkqueue: kblockd blk_mq_timeout_work\nRIP: 0010:null_timeout_rq+0x4e/0x91\nCall Trace:\n ? null_timeout_rq+0x4e/0x91\n blk_mq_handle_expired+0x31/0x4b\n bt_iter+0x68/0x84\n ? bt_tags_iter+0x81/0x81\n __sbitmap_for_each_set.constprop.0+0xb0/0xf2\n ? __blk_mq_complete_request_remote+0xf/0xf\n bt_for_each+0x46/0x64\n ? __blk_mq_complete_request_remote+0xf/0xf\n ? percpu_ref_get_many+0xc/0x2a\n blk_mq_queue_tag_busy_iter+0x14d/0x18e\n blk_mq_timeout_work+0x95/0x127\n process_one_work+0x185/0x263\n worker_thread+0x1b5/0x227\n\nThis is indeed a race problem between null_timeout_rq() and null_poll().\n\nnull_poll()\t\t\t\tnull_timeout_rq()\n spin_lock(\u0026nq-\u003epoll_lock)\n list_splice_init(\u0026nq-\u003epoll_list, \u0026list)\n spin_unlock(\u0026nq-\u003epoll_lock)\n\n while (!list_empty(\u0026list))\n req = list_first_entry()\n list_del_init()\n ...\n blk_mq_add_to_batch()\n // req-\u003erq_next = NULL\n\t\t\t\t\tspin_lock(\u0026nq-\u003epoll_lock)\n\n\t\t\t\t\t// rq-\u003equeuelist-\u003enext == NULL\n\t\t\t\t\tlist_del_init(\u0026rq-\u003equeuelist)\n\n\t\t\t\t\tspin_unlock(\u0026nq-\u003epoll_lock)\n\nFix these problems by setting requests state to MQ_RQ_COMPLETE under\nnq-\u003epoll_lock protection, in which null_timeout_rq() can safely detect\nthis race and early return.\n\nNote this patch just fix the kernel panic when request timeout happen.\n\n[1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/",
"id": "GHSA-vv6q-p28j-9w24",
"modified": "2026-01-23T21:30:36Z",
"published": "2025-10-01T12:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53531"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5a26e45edb4690d58406178b5a9ea4c6dcf2c105"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a0b4a0666beacfe8add9c71d8922475541dbae73"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7cb2e709f2927cc3c76781df3e45de2381b3b9d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/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.
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.