CVE-2024-39501

  1. OpenCVE
  2. Vulnerabilities (CVE)
  3. CVE-2024-39501
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVSS

No CVSS.

References

No reference.

Configurations

No configuration.

History

10 May 2025, 15:15

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: core: sincronizar Actually_probe() y dev_uevent() Sincronizar el uso dev->driver en Actually_probe() y dev_uevent(). Estos pueden ejecutarse en diferentes subprocesos, lo que puede resultar en la siguiente condición de ejecución para dev->desinicialización del controlador: Subproceso n.° 1: ========== reality_probe() { ... probe_failed: ... device_unbind_cleanup( dev) { ... dev->controlador = NULL; // <= La sonda fallida establece dev->driver en NULL ... } ... } Hilo #2: ========== dev_uevent() { ... if (dev->driver) / / Si dev->driver recibe un valor NULL desde reality_probe() de ahora en adelante, // después de la verificación anterior, el sistema falla add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... }realmente_probe() ya tiene el bloqueo. Entonces no es necesario hacer nada allí. A menudo también se llama a dev_uevent() con el bloqueo mantenido. Pero no siempre. Lo que implica que no podemos agregar ningún bloqueo en el propio dev_uevent(). Así que arregle esta ejecución agregando el candado al camino no protegido. Esta es la ruta donde se observa la ejecución anterior: dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0 <= Agregar bloqueo aquí dev_attr_show+0x3a/0xa0 sysfs_kf_seq_show+0x17c/0x250 kernfs_seq_show+0x7c/0x90 seq_read_iter+0x2d7/ 0x940 kernfs_fop_read_iter+0xc6/0x310 vfs_read+0x5bc/0x6b0 ksys_read+0xeb/0x1b0 __x64_sys_read+0x42/0x50 x64_sys_call+0x27ad/0x2d30 do_syscall_64+0xcd/0x1d0 Entry_SYSCALL_64_after_hwframe+0x77/0x7f Casos similares son reportados por syzkaller en https://syzkaller.appspot.com/bug?extid =ffa8143439596313a85a Pero estos se refieren a la *inicialización* de dev->driver dev->driver = drv; Como esto cambia dev->driver a no NULL, estos informes pueden considerarse falsos positivos (aunque esté commit también debería "solucionarlos"). El mismo problema se informó y se intentó solucionar en 2015 en https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/ ya.
Summary (en) In the Linux kernel, the following vulnerability has been resolved: drivers: core: synchronize really_probe() and dev_uevent() Synchronize the dev->driver usage in really_probe() and dev_uevent(). These can run in different threads, what can result in the following race condition for dev->driver uninitialization: Thread #1: ========== really_probe() { ... probe_failed: ... device_unbind_cleanup(dev) { ... dev->driver = NULL; // <= Failed probe sets dev->driver to NULL ... } ... } Thread #2: ========== dev_uevent() { ... if (dev->driver) // If dev->driver is NULLed from really_probe() from here on, // after above check, the system crashes add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... } really_probe() holds the lock, already. So nothing needs to be done there. dev_uevent() is called with lock held, often, too. But not always. What implies that we can't add any locking in dev_uevent() itself. So fix this race by adding the lock to the non-protected path. This is the path where above race is observed: dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0 <= Add lock here dev_attr_show+0x3a/0xa0 sysfs_kf_seq_show+0x17c/0x250 kernfs_seq_show+0x7c/0x90 seq_read_iter+0x2d7/0x940 kernfs_fop_read_iter+0xc6/0x310 vfs_read+0x5bc/0x6b0 ksys_read+0xeb/0x1b0 __x64_sys_read+0x42/0x50 x64_sys_call+0x27ad/0x2d30 do_syscall_64+0xcd/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Similar cases are reported by syzkaller in https://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a But these are regarding the *initialization* of dev->driver dev->driver = drv; As this switches dev->driver to non-NULL these reports can be considered to be false-positives (which should be "fixed" by this commit, as well, though). The same issue was reported and tried to be fixed back in 2015 in https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/ already. (en) Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
References
  • {'url': 'https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69', 'source': 'af854a3a-2127-422b-91ae-364da2661108'}
  • {'url': 'https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c', 'source': 'af854a3a-2127-422b-91ae-364da2661108'}
  • {'url': 'https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad', 'source': 'af854a3a-2127-422b-91ae-364da2661108'}
  • {'url': 'https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea6f564e6', 'source': 'af854a3a-2127-422b-91ae-364da2661108'}
  • {'url': 'https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90', 'source': 'af854a3a-2127-422b-91ae-364da2661108'}
  • {'url': 'https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080', 'source': 'af854a3a-2127-422b-91ae-364da2661108'}
  • {'url': 'https://git.kernel.org/stable/c/c0a40097f0bc81deafc15f9195d1fb54595cd6d0', 'source': 'af854a3a-2127-422b-91ae-364da2661108'}
  • {'url': 'https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721', 'source': 'af854a3a-2127-422b-91ae-364da2661108'}

21 Nov 2024, 09:27

Type Values Removed Values Added
References () https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69 - () https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69 -
References () https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c - () https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c -
References () https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad - () https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad -
References () https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea6f564e6 - () https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea6f564e6 -
References () https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90 - () https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90 -
References () https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080 - () https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080 -
References () https://git.kernel.org/stable/c/c0a40097f0bc81deafc15f9195d1fb54595cd6d0 - () https://git.kernel.org/stable/c/c0a40097f0bc81deafc15f9195d1fb54595cd6d0 -
References () https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721 - () https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721 -
Summary
  • (es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: core: sincronizar Actually_probe() y dev_uevent() Sincronizar el uso dev-&gt;driver en Actually_probe() y dev_uevent(). Estos pueden ejecutarse en diferentes subprocesos, lo que puede resultar en la siguiente condición de ejecución para dev-&gt;desinicialización del controlador: Subproceso n.° 1: ========== reality_probe() { ... probe_failed: ... device_unbind_cleanup( dev) { ... dev-&gt;controlador = NULL; // &lt;= La sonda fallida establece dev-&gt;driver en NULL ... } ... } Hilo #2: ========== dev_uevent() { ... if (dev-&gt;driver) / / Si dev-&gt;driver recibe un valor NULL desde reality_probe() de ahora en adelante, // después de la verificación anterior, el sistema falla add_uevent_var(env, "DRIVER=%s", dev-&gt;driver-&gt;name); ... }realmente_probe() ya tiene el bloqueo. Entonces no es necesario hacer nada allí. A menudo también se llama a dev_uevent() con el bloqueo mantenido. Pero no siempre. Lo que implica que no podemos agregar ningún bloqueo en el propio dev_uevent(). Así que arregle esta ejecución agregando el candado al camino no protegido. Esta es la ruta donde se observa la ejecución anterior: dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0 &lt;= Agregar bloqueo aquí dev_attr_show+0x3a/0xa0 sysfs_kf_seq_show+0x17c/0x250 kernfs_seq_show+0x7c/0x90 seq_read_iter+0x2d7/ 0x940 kernfs_fop_read_iter+0xc6/0x310 vfs_read+0x5bc/0x6b0 ksys_read+0xeb/0x1b0 __x64_sys_read+0x42/0x50 x64_sys_call+0x27ad/0x2d30 do_syscall_64+0xcd/0x1d0 Entry_SYSCALL_64_after_hwframe+0x77/0x7f Casos similares son reportados por syzkaller en https://syzkaller.appspot.com/bug?extid =ffa8143439596313a85a Pero estos se refieren a la *inicialización* de dev-&gt;driver dev-&gt;driver = drv; Como esto cambia dev-&gt;driver a no NULL, estos informes pueden considerarse falsos positivos (aunque esté commit también debería "solucionarlos"). El mismo problema se informó y se intentó solucionar en 2015 en https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/ ya.

12 Jul 2024, 13:15

Type Values Removed Values Added
New CVE
Information

Published : 2024-07-12 13:15

Updated : 2025-05-10 15:15

NVD link : CVE-2024-39501

Mitre link : CVE-2024-39501

CVE.ORG link : CVE-2024-39501

JSON object : View

Products Affected

No product.

CWE

No CWE.