0.0
NA
CVE-2024-39501
Linux Kernel Samsung Device Driver Race Condition Vulnerability
Description
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
INFO
Published Date :
July 12, 2024, 1:15 p.m.
Last Modified :
May 10, 2025, 3:15 p.m.
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Remotely Exploitable :
No
Impact Score :
Exploitability Score :
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2024-39501 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2024-39501 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
CVE Rejected by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
May. 10, 2025
Action Type Old Value New Value -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
May. 10, 2025
Action Type Old Value New Value Changed Description 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/[email protected]/ already. Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. Removed Reference kernel.org: https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69 Removed Reference kernel.org: https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c Removed Reference kernel.org: https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad Removed Reference kernel.org: https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea6f564e6 Removed Reference kernel.org: https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90 Removed Reference kernel.org: https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080 Removed Reference kernel.org: https://git.kernel.org/stable/c/c0a40097f0bc81deafc15f9195d1fb54595cd6d0 Removed Reference kernel.org: https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721 Removed Reference CVE: https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69 Removed Reference CVE: https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c Removed Reference CVE: https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad Removed Reference CVE: https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea6f564e6 Removed Reference CVE: https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90 Removed Reference CVE: https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080 Removed Reference CVE: https://git.kernel.org/stable/c/c0a40097f0bc81deafc15f9195d1fb54595cd6d0 Removed Reference CVE: https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721 -
CVE Modified by af854a3a-2127-422b-91ae-364da2661108
Nov. 21, 2024
Action Type Old Value New Value Added Reference https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69 Added Reference https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c Added Reference https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad Added Reference https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea6f564e6 Added Reference https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90 Added Reference https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080 Added Reference https://git.kernel.org/stable/c/c0a40097f0bc81deafc15f9195d1fb54595cd6d0 Added Reference https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721 -
CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Jul. 12, 2024
Action Type Old Value New Value Added Description 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/[email protected]/ already. Added Reference kernel.org https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea6f564e6 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/c0a40097f0bc81deafc15f9195d1fb54595cd6d0 [No types assigned]
EPSS is a daily estimate of the probability of exploitation activity
being observed over the next 30 days. Following chart shows the EPSS
score history of the vulnerability.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2024-39501 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2024-39501
weaknesses.