You are viewing this page in an unauthorized frame window.
This is a potential security issue, you are being redirected to
https://nvd.nist.gov
An official website of the United States government
Official websites use .gov
A .gov website belongs to an official government organization in the United States.
Secure .gov websites use HTTPS
A lock () or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.
In the Linux kernel, the following vulnerability has been resolved:
driver core: Fix uevent_show() vs driver detach race
uevent_show() wants to de-reference dev->driver->name. There is no clean
way for a device attribute to de-reference dev->driver unless that
attribute is defined via (struct device_driver).dev_groups. Instead, the
anti-pattern of taking the device_lock() in the attribute handler risks
deadlocks with code paths that remove device attributes while holding
the lock.
This deadlock is typically invisible to lockdep given the device_lock()
is marked lockdep_set_novalidate_class(), but some subsystems allocate a
local lockdep key for @dev->mutex to reveal reports of the form:
======================================================
WARNING: possible circular locking dependency detected
6.10.0-rc7+ #275 Tainted: G OE N
------------------------------------------------------
modprobe/2374 is trying to acquire lock:
ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220
but task is already holding lock:
ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&cxl_root_key){+.+.}-{3:3}:
__mutex_lock+0x99/0xc30
uevent_show+0xac/0x130
dev_attr_show+0x18/0x40
sysfs_kf_seq_show+0xac/0xf0
seq_read_iter+0x110/0x450
vfs_read+0x25b/0x340
ksys_read+0x67/0xf0
do_syscall_64+0x75/0x190
entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #0 (kn->active#6){++++}-{0:0}:
__lock_acquire+0x121a/0x1fa0
lock_acquire+0xd6/0x2e0
kernfs_drain+0x1e9/0x200
__kernfs_remove+0xde/0x220
kernfs_remove_by_name_ns+0x5e/0xa0
device_del+0x168/0x410
device_unregister+0x13/0x60
devres_release_all+0xb8/0x110
device_unbind_cleanup+0xe/0x70
device_release_driver_internal+0x1c7/0x210
driver_detach+0x47/0x90
bus_remove_driver+0x6c/0xf0
cxl_acpi_exit+0xc/0x11 [cxl_acpi]
__do_sys_delete_module.isra.0+0x181/0x260
do_syscall_64+0x75/0x190
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The observation though is that driver objects are typically much longer
lived than device objects. It is reasonable to perform lockless
de-reference of a @driver pointer even if it is racing detach from a
device. Given the infrequency of driver unregistration, use
synchronize_rcu() in module_remove_driver() to close any potential
races. It is potentially overkill to suffer synchronize_rcu() just to
handle the rare module removal racing uevent_show() event.
Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1].
Metrics
NVD enrichment efforts reference publicly available information to associate
vector strings. CVSS information contributed by other sources is also
displayed.
By selecting these links, you will be leaving NIST webspace.
We have provided these links to other web sites because they
may have information that would be of interest to you. No
inferences should be drawn on account of other sites being
referenced, or not, from this page. There may be other web
sites that are more appropriate for your purpose. NIST does
not necessarily endorse the views expressed, or concur with
the facts presented on these sites. Further, NIST does not
endorse any commercial products that may be mentioned on
these sites. Please address comments about this page to [email protected].
Title: kernel de Linux
Description: En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: se corrige uevent_show() frente a la ejecución de desconexión del controlador uevent_show() quiere desreferenciar dev->driver->name. No hay una forma clara de que un atributo de dispositivo desreferenciar dev->driver a menos que ese atributo se defina mediante (struct device_driver).dev_groups. En cambio, el antipatrón de tomar device_lock() en el controlador de atributos corre el riesgo de bloqueos con rutas de código que eliminan los atributos del dispositivo mientras mantienen el bloqueo. Este interbloqueo es típicamente invisible para lockdep dado que device_lock() está marcado como lockdep_set_novalidate_class(), pero algunos subsistemas asignan una clave lockdep local para que @dev->mutex revele informes del formato: ======================================================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.10.0-rc7+ #275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 está intentando adquirir el bloqueo: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, en: __kernfs_remove+0xde/0x220 pero la tarea ya tiene el bloqueo: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, en: device_release_driver_internal+0x39/0x210 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x2
In the Linux kernel, the following vulnerability has been resolved:
driver core: Fix uevent_show() vs driver detach race
uevent_show() wants to de-reference dev->driver->name. There is no clean
way for a device attribute to de-reference dev->driver unless that
attribute is defined via (struct device_driver).dev_groups. Instead, the
anti-pattern of taking the device_lock() in the attribute handler risks
deadlocks with code paths that remove device attributes while holding
the lock.
This deadlock is typically invisible to lockdep given the device_lock()
is marked lockdep_set_novalidate_class(), but some subsystems allocate a
local lockdep key for @dev->mutex to reveal reports of the form:
======================================================
WARNING: possible circular locking dependency detected
6.10.0-rc7+ #275 Tainted: G OE N
------------------------------------------------------
modprobe/2374 is trying to acquire lock:
ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220
but task is already holding lock:
ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&cxl_root_key){+.+.}-{3:3}:
__mutex_lock+0x99/0xc30
uevent_show+0xac/0x130
dev_attr_show+0x18/0x40
sysfs_kf_seq_show+0xac/0xf0
seq_read_iter+0x110/0x450
vfs_read+0x25b/0x340
ksys_read+0x67/0xf0
do_syscall_64+0x75/0x190
entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #0 (kn->active#6){++++}-{0:0}:
__lock_acquire+0x121a/0x1fa0
lock_acquire+0xd6/0x2e0
kernfs_drain+0x1e9/0x200
__kernfs_remove+0xde/0x220
kernfs_remove_by_name_ns+0x5e/0xa0
device_del+0x168/0x410
device_unregister+0x13/0x60
devres_release_all+0xb8/0x110
device_unbind_cleanup+0xe/0x70
device_release_driver_internal+0x1c7/0x210
driver_detach+0x47/0x90
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Removed
CVSS V3.1
NIST AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Removed
CWE
NIST CWE-667
Removed
CPE Configuration
OR
*cpe:2.3:o:linux:linux_kernel:6.11:rc1:*:*:*:*:*:*
*cpe:2.3:o:linux:linux_kernel:6.11:rc2:*:*:*:*:*:*
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.10 from (excluding) 6.10.5
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.6.35 from (excluding) 6.6.46
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.1.95 from (excluding) 6.1.105
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.15.162 from (excluding) 5.15.165
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.10.221 from (excluding) 5.10.224
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.4.279 from (excluding) 5.4.282
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 4.19.317 from (excluding) 4.19.320
OR
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 4.19.317 up to (excluding) 4.19.320
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.4.279 up to (excluding) 5.4.282
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.10.221 up to (excluding) 5.10.224
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.15.162 up to (excluding) 5.15.165
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.1.95 up to (excluding) 6.1.105
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.6.35 up to (excluding) 6.6.46
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.10 up to (excluding) 6.10.5
*cpe:2.3:o:linux:linux_kernel:6.11:rc1:*:*:*:*:*:*
*cpe:2.3:o:linux:linux_kernel:6.11:rc2:*:*:*:*:*:*
Changed
Reference Type
https://git.kernel.org/stable/c/15fffc6a5624b13b428bb1c6e9088e32a55eb82c No Types Assigned
In the Linux kernel, the following vulnerability has been resolved:
driver core: Fix uevent_show() vs driver detach race
uevent_show() wants to de-reference dev->driver->name. There is no clean
way for a device attribute to de-reference dev->driver unless that
attribute is defined via (struct device_driver).dev_groups. Instead, the
anti-pattern of taking the device_lock() in the attribute handler risks
deadlocks with code paths that remove device attributes while holding
the lock.
This deadlock is typically invisible to lockdep given the device_lock()
is marked lockdep_set_novalidate_class(), but some subsystems allocate a
local lockdep key for @dev->mutex to reveal reports of the form:
======================================================
WARNING: possible circular locking dependency detected
6.10.0-rc7+ #275 Tainted: G OE N
------------------------------------------------------
modprobe/2374 is trying to acquire lock:
ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220
but task is already holding lock:
ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&cxl_root_key){+.+.}-{3:3}:
__mutex_lock+0x99/0xc30
uevent_show+0xac/0x130
dev_attr_show+0x18/0x40
sysfs_kf_seq_show+0xac/0xf0
seq_read_iter+0x110/0x450
vfs_read+0x25b/0x340
ksys_read+0x67/0xf0
do_syscall_64+0x75/0x190
entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #0 (kn->active#6){++++}-{0:0}:
__lock_acquire+0x121a/0x1fa0
lock_acquire+0xd6/0x2e0
kernfs_drain+0x1e9/0x200
__kernfs_remove+0xde/0x220
kernfs_remove_by_name_ns+0x5e/0xa0
device_del+0x168/0x410
device_unregister+0x13/0x60
devres_release_all+0xb8/0x110
device_unbind_cleanup+0xe/0x70
device_release_driver_internal+0x1c7/0x210
driver_detach+0x47/0x90
) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.
