Medium [CVE-2026-64112] eliminate a race in lock_dwork draining on unmap
This medium-severity Red Hat Linux advisory covers CVE-2026-64112 affecting Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8.
Aggregated and source-linked by VulniPulse. Data sources, validation and limitations.
VulniPulse record published Record updated
Get an email when Red Hat Linux Linux Kernel publishes the next one.
See Red Hat Linux Linux Kernel's last 90 days of advisories first. Then choose one product with live alerts free for life, or a free month of real-time alerts on everything with the severity, the fixed version and the vendor's link (card needed, then US$15/month; we email you before the first charge).
Summary
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(): 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); } 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. 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.
Affected versions
No affected-version range was extracted from the source record. The vendor advisory is authoritative. Check it before change work.
Official advisory · high-confidence parse· fetched 6 days ago·verify at source
Fixed versions
No fixed release is recorded yet. That does not prove no patch exists. Confirm against the vendor advisory.
Official advisory · high-confidence parse· fetched 6 days ago·verify at source
Mitigation checklist
- Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
Official advisory · high-confidence parse· fetched 6 days ago·verify at source
More Red Hat Linux advisories
- CVE-2026-111497Oct 22, 2026Out-of-Bounds Write in Google Brotli Decoder
- CVE-2026-109619Oct 21, 2026fatal error handling retains stale request state leading to use-after-free
- CVE-2026-109618Oct 21, 2026OOM bailout during request parsing leads to memory corruption and RCE
- CVE-2026-119977Oct 31, 2026Arbitrary code execution via predictable upgrade staging paths
- CVE-2026-97229Oct 13, 2026integer overflow issue in CI/CD regular expression compiler
- CVE-2026-64849Aug 17, 2026Unauthenticated full-read SSRF in webhook delivery: _validate_webhook_url bypassed
iPhone and Android apps · New on the App Store
Monitor future Red Hat Linux CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.
Discussion(0)
No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.
Sign in to join the discussion.