CVE-2022-49371

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: fix deadlock in __device_attach<br /> <br /> In __device_attach function, The lock holding logic is as follows:<br /> ...<br /> __device_attach<br /> device_lock(dev) // get lock dev<br /> async_schedule_dev(__device_attach_async_helper, dev); // func<br /> async_schedule_node<br /> async_schedule_node_domain(func)<br /> entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);<br /> /* when fail or work limit, sync to execute func, but<br /> __device_attach_async_helper will get lock dev as<br /> well, which will lead to A-A deadlock. */<br /> if (!entry || atomic_read(&amp;entry_count) &gt; MAX_WORK) {<br /> func;<br /> else<br /> queue_work_node(node, system_unbound_wq, &amp;entry-&gt;work)<br /> device_unlock(dev)<br /> <br /> As shown above, when it is allowed to do async probes, because of<br /> out of memory or work limit, async work is not allowed, to do<br /> sync execute instead. it will lead to A-A deadlock because of<br /> __device_attach_async_helper getting lock dev.<br /> <br /> To fix the deadlock, move the async_schedule_dev outside device_lock,<br /> as we can see, in async_schedule_node_domain, the parameter of<br /> queue_work_node is system_unbound_wq, so it can accept concurrent<br /> operations. which will also not change the code logic, and will<br /> not lead to deadlock.