{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-40925", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-40925" ], "published": "2024-07-12T12:27:31Z", "summary": "block: fix request.queuelist usage in flush", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix request.queuelist usage in flush\n\nFriedrich Weber reported a kernel crash problem and bisected to commit\n81ada09cc25e (\"blk-flush: reuse rq queuelist in flush state machine\").\n\nThe root cause is that we use \"list_move_tail(&rq->queuelist, pending)\"\nin the PREFLUSH/POSTFLUSH sequences. But rq->queuelist.next == xxx since\nit's popped out from plug->cached_rq in __blk_mq_alloc_requests_batch().\nWe don't initialize its queuelist just for this first request, although\nthe queuelist of all later popped requests will be initialized.\n\nFix it by changing to use \"list_add_tail(&rq->queuelist, pending)\" so\nrq->queuelist doesn't need to be initialized. It should be ok since rq\ncan't be on any list when PREFLUSH or POSTFLUSH, has no move actually.\n\nPlease note the commit 81ada09cc25e (\"blk-flush: reuse rq queuelist in\nflush state machine\") also has another requirement that no drivers would\ntouch rq->queuelist after blk_mq_end_request() since we will reuse it to\nadd rq to the post-flush pending list in POSTFLUSH. If this is not true,\nwe will have to revert that commit IMHO.\n\nThis updated version adds \"list_del_init(&rq->queuelist)\" in flush rq\ncallback since the dm layer may submit request of a weird invalid format\n(REQ_FSEQ_PREFLUSH | REQ_FSEQ_POSTFLUSH), which causes double list_add\nif without this \"list_del_init(&rq->queuelist)\". The weird invalid format\nproblem should be fixed in dm layer.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.6.20-1+rpt1", "1:6.6.28-1+rpt1", "1:6.6.31-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.6.20+rpt-rpi-2712", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v6", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7l", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v8", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-2712", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v6", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v7", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v7l", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v8", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-2712", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v6", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v7", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v7l", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v8", "binary_version": "1:6.6.31-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.6.20-1+rpt1": { "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668", "upstream_version": "6.6.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.35" }, "1:6.6.28-1+rpt1": { "linux_commit": "0c341f47adc3578cd5f817aa20ee2b7f9ae6b23e", "upstream_version": "6.6.28", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.35" }, "1:6.6.31-1+rpt1": { "linux_commit": "c1432b4bae5b6582f4d32ba381459f33c34d1424", "upstream_version": "6.6.31", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.35" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-40925" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/fe1e395563ccb051e9dbd8fa99859f5caaad2e71" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/87907bd69721a8506618a954d41a1de3040e88aa" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/d0321c812d89c5910d8da8e4b10c891c6b96ff70" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerable path is reached only through local I/O submission \u2014 `io_uring_enter(2)` with a multi-SQE batch is the sole caller of `blk_start_plug_nr_ios()`, which is what enables the batched request allocation that leaves `rq->queuelist` uninitialized. No network protocol handler reaches `blk_mq_get_new_requests()` with `plug->nr_ios > 1`.\nAC:L - No race is involved: the attacker deterministically controls both the io_uring batch size (making `plug->nr_ios > 1`) and the ordering that puts a flush/FUA bio first in the plug, and write-cache-without-FUA queues (dm/LVM, virtio-blk, SATA/SCSI) are the common default. Tag pressure needed to force the NULL-`next` variant is also attacker-generated by keeping the device queue busy.\nPR:L - Any unprivileged local user with io_uring available (default on mainline) and a writable file or block-backed filesystem can submit the required batch; no capability, CAP_SYS_ADMIN, or device-management privilege is needed. A confined container user with a dm-backed overlay qualifies equally.\nUI:N - The attacker triggers the corrupted `list_move_tail()` entirely from their own io_uring submissions; no victim action, mount, or administrator step is required.\nS:U - The corruption and its consequences stay within the host kernel's own security authority \u2014 kernel heap/list state and block-layer request structures. No hypervisor, IOMMU, or sandbox boundary is crossed by the defect itself.\nC:H - This is real memory corruption, not a bare NULL dereference: `__list_del()` writes a kernel address into a stale `struct request`, and the double-`list_add` on the flush pending list can truncate or loop that list so `flush_end_io()`/`blk_kick_flush()` dereference and re-process requests that have already been ended, yielding use-after-free reads of request/tag state and cross-I/O data exposure into user buffers.\nI:H - The bug gives an uncontrolled kernel-pointer store (`next->prev = prev`) into a stale `struct request` plus corruption of the flush pending list, which can drive `blk_mq_end_request()` on an already-completed request \u2014 a tag double-free and request reuse, i.e. a use-after-free primitive over block-layer objects with attacker-influenced heap contents and on-disk data written to the wrong request.\nA:H - The originally reported symptom is a kernel crash: the NULL-`next` variant faults at address 0x8 while holding `fq->mq_flush_lock` with interrupts disabled, and the list-corruption variant orphans pending flush requests so their submitters hang in D state forever with tags never released, stalling the whole device queue." } } }