https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 03:34:53 +0000 https://vulnerability.circl.lu/vuln/cve-2023-53823 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>block/rq_qos: protect rq_qos apis with a new lock</p> <p>commit 50e34d78815e (&#34;block: disable the elevator int del_gendisk&#34;) move rq_qos_exit() from disk_release() to del_gendisk(), this will introduce some problems:</p> <p>1) If rq_qos_add() is triggered by enabling iocost/iolatency through cgroupfs, then it can concurrent with del_gendisk(), it&#39;s not safe to write &#39;q-&gt;rq_qos&#39; concurrently.</p> <p>2) Activate cgroup policy that is relied on rq_qos will call rq_qos_add() and blkcg_activate_policy(), and if rq_qos_exit() is called in the middle, null-ptr-dereference will be triggered in blkcg_activate_policy().</p> <p>3) blkg_conf_open_bdev() can call blkdev_get_no_open() first to find the disk, then if rq_qos_exit() from del_gendisk() is done before rq_qos_add(), then memory will be leaked.</p> <p>This patch add a new disk level mutex &#39;rq_qos_mutex&#39;:</p> <p>1) The lock will protect rq_qos_exit() directly.</p> <p>2) For wbt that doesn&#39;t relied on blk-cgroup, rq_qos_add() can only be called from disk initialization for now because wbt can&#39;t be destructed until rq_qos_exit(), so it&#39;s safe not to protect wbt for now. Hoever, in case that rq_qos dynamically destruction is supported in the furture, this patch also protect rq_qos_add() from wbt_init() directly, this is enough because blk-sysfs already synchronize writers with disk removal.</p> <p>3) For iocost and iolatency, in order to synchronize disk removal and cgro…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>block/rq_qos: protect rq_qos apis with a new lock</p> <p>commit 50e34d78815e (&#34;block: disable the elevator int del_gendisk&#34;) move rq_qos_exit() from disk_release() to del_gendisk(), this will introduce some problems:</p> <p>1) If rq_qos_add() is triggered by enabling iocost/iolatency through cgroupfs, then it can concurrent with del_gendisk(), it&#39;s not safe to write &#39;q-&gt;rq_qos&#39; concurrently.</p> <p>2) Activate cgroup policy that is relied on rq_qos will call rq_qos_add() and blkcg_activate_policy(), and if rq_qos_exit() is called in the middle, null-ptr-dereference will be triggered in blkcg_activate_policy().</p> <p>3) blkg_conf_open_bdev() can call blkdev_get_no_open() first to find the disk, then if rq_qos_exit() from del_gendisk() is done before rq_qos_add(), then memory will be leaked.</p> <p>This patch add a new disk level mutex &#39;rq_qos_mutex&#39;:</p> <p>1) The lock will protect rq_qos_exit() directly.</p> <p>2) For wbt that doesn&#39;t relied on blk-cgroup, rq_qos_add() can only be called from disk initialization for now because wbt can&#39;t be destructed until rq_qos_exit(), so it&#39;s safe not to protect wbt for now. Hoever, in case that rq_qos dynamically destruction is supported in the furture, this patch also protect rq_qos_add() from wbt_init() directly, this is enough because blk-sysfs already synchronize writers with disk removal.</p> <p>3) For iocost and iolatency, in order to synchronize disk removal and cgro…</p> https://vulnerability.circl.lu/vuln/cve-2023-53823