CVE-2023-53823

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block/rq_qos: protect rq_qos apis with a new lock<br /> <br /> commit 50e34d78815e ("block: disable the elevator int del_gendisk")<br /> move rq_qos_exit() from disk_release() to del_gendisk(), this will<br /> introduce some problems:<br /> <br /> 1) If rq_qos_add() is triggered by enabling iocost/iolatency through<br /> cgroupfs, then it can concurrent with del_gendisk(), it&amp;#39;s not safe to<br /> write &amp;#39;q-&gt;rq_qos&amp;#39; concurrently.<br /> <br /> 2) Activate cgroup policy that is relied on rq_qos will call<br /> rq_qos_add() and blkcg_activate_policy(), and if rq_qos_exit() is<br /> called in the middle, null-ptr-dereference will be triggered in<br /> blkcg_activate_policy().<br /> <br /> 3) blkg_conf_open_bdev() can call blkdev_get_no_open() first to find the<br /> disk, then if rq_qos_exit() from del_gendisk() is done before<br /> rq_qos_add(), then memory will be leaked.<br /> <br /> This patch add a new disk level mutex &amp;#39;rq_qos_mutex&amp;#39;:<br /> <br /> 1) The lock will protect rq_qos_exit() directly.<br /> <br /> 2) For wbt that doesn&amp;#39;t relied on blk-cgroup, rq_qos_add() can only be<br /> called from disk initialization for now because wbt can&amp;#39;t be<br /> destructed until rq_qos_exit(), so it&amp;#39;s safe not to protect wbt for<br /> now. Hoever, in case that rq_qos dynamically destruction is supported<br /> in the furture, this patch also protect rq_qos_add() from wbt_init()<br /> directly, this is enough because blk-sysfs already synchronize<br /> writers with disk removal.<br /> <br /> 3) For iocost and iolatency, in order to synchronize disk removal and<br /> cgroup configuration, the lock is held after blkdev_get_no_open()<br /> from blkg_conf_open_bdev(), and is released in blkg_conf_exit().<br /> In order to fix the above memory leak, disk_live() is checked after<br /> holding the new lock.