CVE-2026-64112
In the Linux kernel, the following vulnerability has been resolved:
rbd: eliminate a race in lock_dwork draining on unmap
Given how rbd_lock_add_request() and rbd_img_exclusive_lock() are written, lock_dwork may be (re)queued more than it's actually needed: for example in case a new I/O request comes in while we are in the middle of rbd_acquire_lock() on behalf of another I/O request. This is expected and with rbd_release_lock() preemptively canceling lock_dwork is benign under normal operation.
A more problematic example is maybe_kick_acquire():
It's not unrealistic for lock_dwork to get canceled right after delayed_work_pending() returns true and for mod_delayed_work() to requeue it right there anyway. This is a classic TOCTOU race.
Leer descripción completaMostrar menos
When it comes to unmapping the image, there is an implicit assumption of no self-initiated exclusive lock activity past the point of return from rbd_dev_image_unlock() which unlocks the lock if it happens to be held. This unlock is assumed to be final and lock_dwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again. However, lock_dwork is canceled only in cancel_tasks_sync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybe_kick_acquire(). This may result in rbd_acquire_lock() executing after rbd_dev_device_release() and rbd_dev_image_release() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated
in rbd_dev_header_info() which is called via rbd_dev_refresh() from rbd_post_acquire_action().
Redo exclusive lock task draining to provide saner semantics and try to meet the assumptions around rbd_dev_image_unlock().
Detalles técnicos trazas, registros y código del informe original
if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {
dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev);
mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0);
}
rbd_assert(rbd_image_format_valid(rbd_dev->image_format));CVSS
- Versión: 3.1
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Puntuación base: 7.8
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días: 0.10%
- Percentil entre todas las CVEs puntuadas: 1
- Fecha de la puntuación: 6/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
🎯 Técnicas ATT&CK
Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.
- Explotación
T1068Exploitation for Privilege Escalationprivilege escalation85 % - Impacto principal
T1499.004Application or System Exploitationimpact75 % - Impacto secundario
T1565.001Stored Data Manipulationimpact65 %
Vulnerabilidad de race condition (CWE-367) en kernel Linux con acceso local y privilegios de usuario (AV:L, PR:L). Permite esquivar mecanismos de sincronización para causar DoS (assert violation en rbd_dev_header_info) o corrupción de memoria (freed structures).
Inferido por nuestro agente de análisis a partir de la descripción oficial, el vector CVSS y la CWE, y comprobado por un supervisor. Puede contener errores.
🛡️ Mitigaciones ATT&CK que cubren estas técnicas
Tecnologías afectadas (1)
CWE
- CWE-367
Referencias
JSON original (NVD)
Mostrar
{
"id": "CVE-2026-64112",
"cveTags": [],
"metrics": {
"cvssMetricV31": [
{
"type": "Secondary",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"cvssData": {
"scope": "UNCHANGED",
"version": "3.1",
"baseScore": 7.8,
"attackVector": "LOCAL",
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"integrityImpact": "HIGH",
"userInteraction": "NONE",
"attackComplexity": "LOW",
"availabilityImpact": "HIGH",
"privilegesRequired": "LOW",
"confidentialityImpact": "HIGH"
},
"impactScore": 5.9,
"exploitabilityScore": 1.8
}
]
},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "fd22aef8b47cfc068448df65c1183698b0abd815",
"lessThan": "3427d7ae38337066ce88b68302e285d344ab756b",
"versionType": "git"
},
{
"status": "affected",
"version": "fd22aef8b47cfc068448df65c1183698b0abd815",
"lessThan": "9dcd4f5c99b491c37be90b0bd9988db48225fb75",
"versionType": "git"
},
{
"status": "affected",
"version": "fd22aef8b47cfc068448df65c1183698b0abd815",
"lessThan": "9400efc76b42c751211974a25c91d2c19c65b01b",
"versionType": "git"
},
{
"status": "affected",
"version": "fd22aef8b47cfc068448df65c1183698b0abd815",
"lessThan": "9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90",
"versionType": "git"
}
],
"programFiles": [
"drivers/block/rbd.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "4.12"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "4.12",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.12.92",
"versionType": "semver",
"lessThanOrEqual": "6.12.*"
},
{
"status": "unaffected",
"version": "6.18.34",
"versionType": "semver",
"lessThanOrEqual": "6.18.*"
},
{
"status": "unaffected",
"version": "7.0.11",
"versionType": "semver",
"lessThanOrEqual": "7.0.*"
},
{
"status": "unaffected",
"version": "7.1",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"drivers/block/rbd.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-07-19T16:17:52.567",
"references": [
{
"url": "https://git.kernel.org/stable/c/3427d7ae38337066ce88b68302e285d344ab756b",
"tags": [
"Patch"
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/9400efc76b42c751211974a25c91d2c19c65b01b",
"tags": [
"Patch"
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/9dcd4f5c99b491c37be90b0bd9988db48225fb75",
"tags": [
"Patch"
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90",
"tags": [
"Patch"
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Analyzed",
"weaknesses": [
{
"type": "Primary",
"source": "nvd@nist.gov",
"description": [
{
"lang": "en",
"value": "CWE-367"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrbd: eliminate a race in lock_dwork draining on unmap\n\nGiven how rbd_lock_add_request() and rbd_img_exclusive_lock() are\nwritten, lock_dwork may be (re)queued more than it's actually needed:\nfor example in case a new I/O request comes in while we are in the\nmiddle of rbd_acquire_lock() on behalf of another I/O request. This is\nexpected and with rbd_release_lock() preemptively canceling lock_dwork\nis benign under normal operation.\n\nA more problematic example is maybe_kick_acquire():\n\n if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {\n dout(\"%s rbd_dev %p kicking lock_dwork\\n\", __func__, rbd_dev);\n mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0);\n }\n\nIt's not unrealistic for lock_dwork to get canceled right after\ndelayed_work_pending() returns true and for mod_delayed_work() to\nrequeue it right there anyway. This is a classic TOCTOU race.\n\nWhen it comes to unmapping the image, there is an implicit assumption\nof no self-initiated exclusive lock activity past the point of return\nfrom rbd_dev_image_unlock() which unlocks the lock if it happens to be\nheld. This unlock is assumed to be final and lock_dwork (as well as\nall other exclusive lock tasks, really) isn't expected to get queued\nagain. However, lock_dwork is canceled only in cancel_tasks_sync()\n(i.e. later in the unmap sequence) and on top of that the cancellation\ncan get in effect nullified by maybe_kick_acquire(). This may result\nin rbd_acquire_lock() executing after rbd_dev_device_release() and\nrbd_dev_image_release() run and free and/or reset a bunch of things.\nOne of the possible failure modes then is a violated\n\n rbd_assert(rbd_image_format_valid(rbd_dev->image_format));\n\nin rbd_dev_header_info() which is called via rbd_dev_refresh() from\nrbd_post_acquire_action().\n\nRedo exclusive lock task draining to provide saner semantics and try\nto meet the assumptions around rbd_dev_image_unlock()."
}
],
"lastModified": "2026-08-12T15:50:34.470",
"configurations": [
{
"nodes": [
{
"negate": false,
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"vulnerable": true,
"matchCriteriaId": "B85C8C81-E8EA-41D1-85CB-349D7F70DA52",
"versionEndExcluding": "6.12.92",
"versionStartIncluding": "4.12"
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"vulnerable": true,
"matchCriteriaId": "A4B1EF6D-18D7-4838-BC37-7499D5DCC3C0",
"versionEndExcluding": "6.18.34",
"versionStartIncluding": "6.13"
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"vulnerable": true,
"matchCriteriaId": "0520D091-FC52-4A50-AF07-70AE7D08B750",
"versionEndExcluding": "7.0.11",
"versionStartIncluding": "6.19"
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:*",
"vulnerable": true,
"matchCriteriaId": "B1EF7059-E670-45F4-B422-54C40FA86390"
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:*",
"vulnerable": true,
"matchCriteriaId": "0D38F0BF-A728-4133-A358-D44A2F7EE6D6"
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:*",
"vulnerable": true,
"matchCriteriaId": "EC732D08-5F7B-46D9-B154-E60C7F4F0A97"
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:*",
"vulnerable": true,
"matchCriteriaId": "E5910A9D-F60A-409A-B486-FE66BFEBA9B9"
}
],
"operator": "OR"
}
]
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}