{ "schema_version": "1.6.1", "id": "RPI-CVE-2023-53823", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2023-53823" ], "published": "2025-12-09T01:31:24Z", "summary": "block/rq_qos: protect rq_qos apis with a new lock", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock/rq_qos: protect rq_qos apis with a new lock\n\ncommit 50e34d78815e (\"block: disable the elevator int del_gendisk\")\nmove rq_qos_exit() from disk_release() to del_gendisk(), this will\nintroduce some problems:\n\n1) If rq_qos_add() is triggered by enabling iocost/iolatency through\n cgroupfs, then it can concurrent with del_gendisk(), it's not safe to\n write 'q->rq_qos' concurrently.\n\n2) Activate cgroup policy that is relied on rq_qos will call\n rq_qos_add() and blkcg_activate_policy(), and if rq_qos_exit() is\n called in the middle, null-ptr-dereference will be triggered in\n blkcg_activate_policy().\n\n3) blkg_conf_open_bdev() can call blkdev_get_no_open() first to find the\n disk, then if rq_qos_exit() from del_gendisk() is done before\n rq_qos_add(), then memory will be leaked.\n\nThis patch add a new disk level mutex 'rq_qos_mutex':\n\n1) The lock will protect rq_qos_exit() directly.\n\n2) For wbt that doesn't relied on blk-cgroup, rq_qos_add() can only be\n called from disk initialization for now because wbt can't be\n destructed until rq_qos_exit(), so it's safe not to protect wbt for\n now. Hoever, in case that rq_qos dynamically destruction is supported\n in the furture, this patch also protect rq_qos_add() from wbt_init()\n directly, this is enough because blk-sysfs already synchronize\n writers with disk removal.\n\n3) For iocost and iolatency, in order to synchronize disk removal and\n cgroup configuration, the lock is held after blkdev_get_no_open()\n from blkg_conf_open_bdev(), and is released in blkg_conf_exit().\n In order to fix the above memory leak, disk_live() is checked after\n holding the new lock.", "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.1.21-1+rpt1", "1:6.1.47-1+rpt2", "1:6.1.47-1+rpt4", "1:6.1.54-1+rpt2", "1:6.1.58-1+rpt2", "1:6.1.63-1+rpt1", "1:6.1.73-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi1-rpi-v6", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7l", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v8", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v6", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7l", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v8", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-2712", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v6", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v7", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v7l", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v8", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-2712", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v6", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v7", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v7l", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v8", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-2712", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v6", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v7", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v7l", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v8", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-2712", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v6", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v7", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v7l", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v8", "binary_version": "1:6.1.73-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.1.21-1+rpt1": { "linux_commit": "0afb5e98488aed7017b9bf321b575d0177feb7ed", "upstream_version": "6.1.21", "assessment": "commit ancestry (strak rule)", "upstream_fixed": null }, "1:6.1.47-1+rpt2": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": null }, "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": null, "compiled_filter": false }, "1:6.1.54-1+rpt2": { "linux_commit": "2906f7abdc03d4a92b6b0e2e0c87ea2a9dffe8f7", "upstream_version": "6.1.54", "assessment": "commit ancestry (strak rule)", "upstream_fixed": null }, "1:6.1.58-1+rpt2": { "linux_commit": "ccf1586ad0663fa91238ac56abf6340d6d740d18", "upstream_version": "6.1.58", "assessment": "commit ancestry (strak rule)", "upstream_fixed": null }, "1:6.1.63-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.63", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": null }, "1:6.1.73-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.73", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": null } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2023-53823" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/16398b4638b5cd8c1dc95fc940a1591a801d53ce" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a13bd91be22318768d55470cbc0b0f4488ef9edf" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:24:39Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - Both sides of the race are driven through local interfaces \u2014 a cgroupfs write to `io.latency`/`io.cost.qos` reaching `rq_qos_add()`, and a block-device removal reaching `del_gendisk()`\u2192`rq_qos_exit()`. There is no remote or network-facing path into the block rq_qos layer.\nAC:L - The attacker controls both sides: they can loop the `io.latency` write against any device by MAJ:MIN (no permission check in `blkg_conf_open_bdev()`) while triggering repeated disk teardown (loop/nbd device delete), and can stretch the `rq_qos_add()`\u2192`timer_setup()` window arbitrarily by populating the queue with thousands of blkgs so `blkcg_activate_policy()` spends a long time in GFP_KERNEL allocation and retry.\nPR:L - No capability check exists on the path \u2014 `iolatency_set_limit()`/`blkg_conf_open_bdev()` gate only on cgroupfs file permissions, and `cgroup_add_file()` creates interface files owned by `current_fsuid()`, so an unprivileged user with a delegated cgroup v2 subtree (systemd delegation, container runtimes) can write `io.latency` and target any block device on the system.\nUI:N - The attacker performs both the cgroup configuration write and the disk removal themselves; no action by any other user or administrator is needed.\nS:U - The corruption is confined to kernel heap objects and the block layer's request_queue within the same security authority; there is no crossing of a VM, IOMMU, or sandbox boundary.\nC:H - The unsynchronized `q->rq_qos` update leaves freed `rq_qos` objects linked in the chain and dangling `blk_iolatency`/gendisk pointers, giving a use-after-free read primitive over reclaimed slab memory that can be groomed to disclose arbitrary kernel data.\nI:H - `blk_iolatency_init()` continues writing (`timer_setup()`, `INIT_WORK()`) into the object already freed by `blkcg_iolatency_exit()`, and `__rq_qos_throttle()` performs an indirect call through `rqos->ops->throttle` read from freed memory \u2014 a heap-spray-controllable arbitrary write and control-flow hijack.\nA:H - The race reliably produces kernel oopses \u2014 a NULL dereference through `iolat->blkiolat` set to NULL by `iolatency_pd_init()`, plus use-after-free faults on the rq_qos chain during I/O submission and from the leaked object's timer firing after the disk is released." } } }