{"api_version":"1","generated_at":"2026-07-20T14:42:10+00:00","cve":"CVE-2026-64112","urls":{"html":"https://cve.report/CVE-2026-64112","api":"https://cve.report/api/cve/CVE-2026-64112.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-64112","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-64112"},"summary":{"title":"rbd: eliminate a race in lock_dwork draining on unmap","description":"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().","state":"PUBLISHED","assigner":"Linux","published_at":"2026-07-19 16:17:52","updated_at":"2026-07-20 07:16:42"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/9400efc76b42c751211974a25c91d2c19c65b01b","name":"https://git.kernel.org/stable/c/9400efc76b42c751211974a25c91d2c19c65b01b","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/9dcd4f5c99b491c37be90b0bd9988db48225fb75","name":"https://git.kernel.org/stable/c/9dcd4f5c99b491c37be90b0bd9988db48225fb75","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90","name":"https://git.kernel.org/stable/c/9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/3427d7ae38337066ce88b68302e285d344ab756b","name":"https://git.kernel.org/stable/c/3427d7ae38337066ce88b68302e285d344ab756b","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-64112","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64112","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected fd22aef8b47cfc068448df65c1183698b0abd815 3427d7ae38337066ce88b68302e285d344ab756b git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected fd22aef8b47cfc068448df65c1183698b0abd815 9dcd4f5c99b491c37be90b0bd9988db48225fb75 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected fd22aef8b47cfc068448df65c1183698b0abd815 9400efc76b42c751211974a25c91d2c19c65b01b git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected fd22aef8b47cfc068448df65c1183698b0abd815 9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4.12","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 4.12 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.92 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.34 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.0.11 7.0.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["drivers/block/rbd.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"3427d7ae38337066ce88b68302e285d344ab756b","status":"affected","version":"fd22aef8b47cfc068448df65c1183698b0abd815","versionType":"git"},{"lessThan":"9dcd4f5c99b491c37be90b0bd9988db48225fb75","status":"affected","version":"fd22aef8b47cfc068448df65c1183698b0abd815","versionType":"git"},{"lessThan":"9400efc76b42c751211974a25c91d2c19c65b01b","status":"affected","version":"fd22aef8b47cfc068448df65c1183698b0abd815","versionType":"git"},{"lessThan":"9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90","status":"affected","version":"fd22aef8b47cfc068448df65c1183698b0abd815","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["drivers/block/rbd.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"4.12"},{"lessThan":"4.12","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.92","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.34","versionType":"semver"},{"lessThanOrEqual":"7.0.*","status":"unaffected","version":"7.0.11","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.92","versionStartIncluding":"4.12","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.34","versionStartIncluding":"4.12","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.0.11","versionStartIncluding":"4.12","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.1","versionStartIncluding":"4.12","vulnerable":true}],"negate":false,"operator":"OR"}]}],"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()."}],"providerMetadata":{"dateUpdated":"2026-07-20T06:41:49.607Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/3427d7ae38337066ce88b68302e285d344ab756b"},{"url":"https://git.kernel.org/stable/c/9dcd4f5c99b491c37be90b0bd9988db48225fb75"},{"url":"https://git.kernel.org/stable/c/9400efc76b42c751211974a25c91d2c19c65b01b"},{"url":"https://git.kernel.org/stable/c/9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90"}],"title":"rbd: eliminate a race in lock_dwork draining on unmap","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-64112","datePublished":"2026-07-19T15:40:13.652Z","dateReserved":"2026-07-19T07:54:57.035Z","dateUpdated":"2026-07-20T06:41:49.607Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-07-19 16:17:52","lastModifiedDate":"2026-07-20 07:16:42","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"64112","Ordinal":"1","Title":"rbd: eliminate a race in lock_dwork draining on unmap","CVE":"CVE-2026-64112","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"64112","Ordinal":"1","NoteData":"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().","Type":"Description","Title":"rbd: eliminate a race in lock_dwork draining on unmap"}]}}}