CVE-2024-39501 (GCVE-0-2024-39501)
Vulnerability from cvelistv5 – Published: 2024-07-12 12:20 – Updated: 2025-05-10 14:14
VLAI
EPSS
VEX
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Show details on NVD website{
"containers": {
"cna": {
"providerMetadata": {
"dateUpdated": "2025-05-10T14:14:44.417Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"rejectedReasons": [
{
"lang": "en",
"value": "This CVE ID has been rejected or withdrawn by its CVE Numbering Authority."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-39501",
"datePublished": "2024-07-12T12:20:34.980Z",
"dateRejected": "2025-05-10T14:14:44.417Z",
"dateReserved": "2024-06-25T14:23:23.752Z",
"dateUpdated": "2025-05-10T14:14:44.417Z",
"state": "REJECTED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1",
"vulnerability-lookup:meta": {
"fkie_nvd": {
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: core: synchronize really_probe() and dev_uevent()\n\nSynchronize the dev-\u003edriver usage in really_probe() and dev_uevent().\nThese can run in different threads, what can result in the following\nrace condition for dev-\u003edriver uninitialization:\n\nThread #1:\n==========\n\nreally_probe() {\n...\nprobe_failed:\n...\ndevice_unbind_cleanup(dev) {\n ...\n dev-\u003edriver = NULL; // \u003c= Failed probe sets dev-\u003edriver to NULL\n ...\n }\n...\n}\n\nThread #2:\n==========\n\ndev_uevent() {\n...\nif (dev-\u003edriver)\n // If dev-\u003edriver is NULLed from really_probe() from here on,\n // after above check, the system crashes\n add_uevent_var(env, \"DRIVER=%s\", dev-\u003edriver-\u003ename);\n...\n}\n\nreally_probe() holds the lock, already. So nothing needs to be done\nthere. dev_uevent() is called with lock held, often, too. But not\nalways. What implies that we can\u0027t add any locking in dev_uevent()\nitself. So fix this race by adding the lock to the non-protected\npath. This is the path where above race is observed:\n\n dev_uevent+0x235/0x380\n uevent_show+0x10c/0x1f0 \u003c= Add lock here\n dev_attr_show+0x3a/0xa0\n sysfs_kf_seq_show+0x17c/0x250\n kernfs_seq_show+0x7c/0x90\n seq_read_iter+0x2d7/0x940\n kernfs_fop_read_iter+0xc6/0x310\n vfs_read+0x5bc/0x6b0\n ksys_read+0xeb/0x1b0\n __x64_sys_read+0x42/0x50\n x64_sys_call+0x27ad/0x2d30\n do_syscall_64+0xcd/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nSimilar cases are reported by syzkaller in\n\nhttps://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a\n\nBut these are regarding the *initialization* of dev-\u003edriver\n\ndev-\u003edriver = drv;\n\nAs this switches dev-\u003edriver to non-NULL these reports can be considered\nto be false-positives (which should be \"fixed\" by this commit, as well,\nthough).\n\nThe same issue was reported and tried to be fixed back in 2015 in\n\nhttps://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/\n\nalready."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: core: sincronizar Actually_probe() y dev_uevent() Sincronizar el uso dev-\u0026gt;driver en Actually_probe() y dev_uevent(). Estos pueden ejecutarse en diferentes subprocesos, lo que puede resultar en la siguiente condici\u00f3n de ejecuci\u00f3n para dev-\u0026gt;desinicializaci\u00f3n del controlador: Subproceso n.\u00b0 1: ========== reality_probe() { ... probe_failed: ... device_unbind_cleanup( dev) { ... dev-\u0026gt;controlador = NULL; // \u0026lt;= La sonda fallida establece dev-\u0026gt;driver en NULL ... } ... } Hilo #2: ========== dev_uevent() { ... if (dev-\u0026gt;driver) / / Si dev-\u0026gt;driver recibe un valor NULL desde reality_probe() de ahora en adelante, // despu\u00e9s de la verificaci\u00f3n anterior, el sistema falla add_uevent_var(env, \"DRIVER=%s\", dev-\u0026gt;driver-\u0026gt;name); ... }realmente_probe() ya tiene el bloqueo. Entonces no es necesario hacer nada all\u00ed. A menudo tambi\u00e9n se llama a dev_uevent() con el bloqueo mantenido. Pero no siempre. Lo que implica que no podemos agregar ning\u00fan bloqueo en el propio dev_uevent(). As\u00ed que arregle esta ejecuci\u00f3n agregando el candado al camino no protegido. Esta es la ruta donde se observa la ejecuci\u00f3n anterior: dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0 \u0026lt;= Agregar bloqueo aqu\u00ed 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\u00f3n* de dev-\u0026gt;driver dev-\u0026gt;driver = drv; Como esto cambia dev-\u0026gt;driver a no NULL, estos informes pueden considerarse falsos positivos (aunque est\u00e9 commit tambi\u00e9n deber\u00eda \"solucionarlos\"). El mismo problema se inform\u00f3 y se intent\u00f3 solucionar en 2015 en https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/ ya."
}
],
"id": "CVE-2024-39501",
"lastModified": "2024-11-21T09:27:50.060",
"published": "2024-07-12T13:15:12.600",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea6f564e6"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c0a40097f0bc81deafc15f9195d1fb54595cd6d0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"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"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
},
"nvd": {
"cve": {
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority."
}
],
"id": "CVE-2024-39501",
"lastModified": "2025-05-10T15:15:58.887",
"metrics": {},
"published": "2024-07-12T13:15:12.600",
"references": [],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Rejected"
}
},
"redhat_vex": {
"aggregate_severity": "None",
"current_release_date": "2026-06-28T07:57:41+00:00",
"cve": "CVE-2024-39501",
"id": "CVE-2024-39501",
"initial_release_date": "2024-07-12T00:00:00+00:00",
"product_status:fixed": "430",
"product_status:known_affected": "64",
"product_status:known_not_affected": "8",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: drivers: core: synchronize really_probe() and dev_uevent()",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-39501.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-10-03T23:59:44Z",
"cve": "CVE-2024-39501",
"id": "CVE-2024-39501",
"initial_release_date": "2024-07-16T02:35:20Z",
"product_status:known_affected": "586",
"product_status:known_not_affected": "12",
"product_status:recommended": "757",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2024-39501",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-39501.json",
"version": "99"
},
"vulnrichment": {
"containers": {
"cna": {
"providerMetadata": {
"dateUpdated": "2025-05-10T14:14:44.417Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"rejectedReasons": [
{
"lang": "en",
"value": "This CVE ID has been rejected or withdrawn by its CVE Numbering Authority."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-39501",
"datePublished": "2024-07-12T12:20:34.980Z",
"dateRejected": "2025-05-10T14:14:44.417Z",
"dateReserved": "2024-06-25T14:23:23.752Z",
"dateUpdated": "2025-05-10T14:14:44.417Z",
"state": "REJECTED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
}
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.
Loading…