Message-ID: <2025061821-CVE-2022-50149-5467@gregkh>
Date: Wed, 18 Jun 2025 13:03:34 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2022-50149: driver core: fix potential deadlock in __driver_attach

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

driver core: fix potential deadlock in __driver_attach

In __driver_attach function, There are also AA deadlock problem,
like the commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").

stack like commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
list below:
    In __driver_attach function, The lock holding logic is as follows:
    ...
    __driver_attach
    if (driver_allows_async_probing(drv))
      device_lock(dev)      // get lock dev
        async_schedule_dev(__driver_attach_async_helper, dev); // func
          async_schedule_node
            async_schedule_node_domain(func)
              entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
              /* when fail or work limit, sync to execute func, but
                 __driver_attach_async_helper will get lock dev as
                 will, which will lead to A-A deadlock.  */
              if (!entry || atomic_read(&entry_count) > MAX_WORK) {
                func;
              else
                queue_work_node(node, system_unbound_wq, &entry->work)
      device_unlock(dev)

    As above show, when it is allowed to do async probes, because of
    out of memory or work limit, async work is not be allowed, to do
    sync execute instead. it will lead to A-A deadlock because of
    __driver_attach_async_helper getting lock dev.

Reproduce:
and it can be reproduce by make the condition
(if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like
below:

[  370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[  370.787154] task:swapper/0       state:D stack:    0 pid:    1 ppid:
0 flags:0x00004000
[  370.788865] Call Trace:
[  370.789374]  <TASK>
[  370.789841]  __schedule+0x482/0x1050
[  370.790613]  schedule+0x92/0x1a0
[  370.791290]  schedule_preempt_disabled+0x2c/0x50
[  370.792256]  __mutex_lock.isra.0+0x757/0xec0
[  370.793158]  __mutex_lock_slowpath+0x1f/0x30
[  370.794079]  mutex_lock+0x50/0x60
[  370.794795]  __device_driver_lock+0x2f/0x70
[  370.795677]  ? driver_probe_device+0xd0/0xd0
[  370.796576]  __driver_attach_async_helper+0x1d/0xd0
[  370.797318]  ? driver_probe_device+0xd0/0xd0
[  370.797957]  async_schedule_node_domain+0xa5/0xc0
[  370.798652]  async_schedule_node+0x19/0x30
[  370.799243]  __driver_attach+0x246/0x290
[  370.799828]  ? driver_allows_async_probing+0xa0/0xa0
[  370.800548]  bus_for_each_dev+0x9d/0x130
[  370.801132]  driver_attach+0x22/0x30
[  370.801666]  bus_add_driver+0x290/0x340
[  370.802246]  driver_register+0x88/0x140
[  370.802817]  ? virtio_scsi_init+0x116/0x116
[  370.803425]  scsi_register_driver+0x1a/0x30
[  370.804057]  init_sd+0x184/0x226
[  370.804533]  do_one_initcall+0x71/0x3a0
[  370.805107]  kernel_init_freeable+0x39a/0x43a
[  370.805759]  ? rest_init+0x150/0x150
[  370.806283]  kernel_init+0x26/0x230
[  370.806799]  ret_from_fork+0x1f/0x30

To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock.

The Linux kernel CVE team has assigned CVE-2022-50149 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.1 with commit ef0ff68351be4fd83bec2d797f0efdc0174a55a4 and fixed in 5.4.211 with commit 8191b6cd9ada09b675f17446d5872eb1f77685cb
	Issue introduced in 5.1 with commit ef0ff68351be4fd83bec2d797f0efdc0174a55a4 and fixed in 5.10.137 with commit a93f33aeef4e6a94ae9c9d3f5b2f9085ad0572ec
	Issue introduced in 5.1 with commit ef0ff68351be4fd83bec2d797f0efdc0174a55a4 and fixed in 5.15.61 with commit 733ab0c19bf17f6ad7c2b580ede006e369d5ab1b
	Issue introduced in 5.1 with commit ef0ff68351be4fd83bec2d797f0efdc0174a55a4 and fixed in 5.18.18 with commit 779b634714c51d05baaeff4868ce2fd9fc7399bf
	Issue introduced in 5.1 with commit ef0ff68351be4fd83bec2d797f0efdc0174a55a4 and fixed in 5.19.2 with commit 37f908038402c9b8325763f306a1c65d88757e15
	Issue introduced in 5.1 with commit ef0ff68351be4fd83bec2d797f0efdc0174a55a4 and fixed in 6.0 with commit 70fe758352cafdee72a7b13bf9db065f9613ced8

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-50149
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/base/dd.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/8191b6cd9ada09b675f17446d5872eb1f77685cb
	https://git.kernel.org/stable/c/a93f33aeef4e6a94ae9c9d3f5b2f9085ad0572ec
	https://git.kernel.org/stable/c/733ab0c19bf17f6ad7c2b580ede006e369d5ab1b
	https://git.kernel.org/stable/c/779b634714c51d05baaeff4868ce2fd9fc7399bf
	https://git.kernel.org/stable/c/37f908038402c9b8325763f306a1c65d88757e15
	https://git.kernel.org/stable/c/70fe758352cafdee72a7b13bf9db065f9613ced8

Powered by blists - more mailing lists