CVE-2026-23047 libceph: make calc_target() set t->paused, not just clear it
A flaw in the Linux kernel Ceph client causes RBD image unmap operations to hang indefinitely, leading to a local denial of service.
- Exploited in the wild
- Not known
- Login needed
- Not needed
- Attackable
- Local or same network only
- Victim action needed
- Not needed
- Fix
- Available
What is CVE-2026-23047?
CVE-2026-23047 is a denial of service vulnerability in Linux, published on 4 Feb 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Official description
In the Linux kernel, the following vulnerability has been resolved:
libceph: make calc_target() set t->paused, not just clear it
Currently calc_target() clears t->paused if the request shouldn't be paused anymore, but doesn't ever set t->paused even though it's able to determine when the request should be paused. Setting t->paused is left to __submit_request() which is fine for regular requests but doesn't work for linger requests -- since __submit_request() doesn't operate on linger requests, there is nowhere for lreq->t.paused to be set. One consequence of this is that watches don't get reestablished on paused -> unpaused transitions in cases where requests have been paused long enough for the (paused) unwatch request to time out and for the subsequent (re)watch request to enter the paused state. On top of the watch not getting reestablished, rbd_reregister_watch() gets stuck with rbd_dev->watch_mutex held:
rbd_register_watch __rbd_register_watch ceph_osdc_watch linger_reg_commit_wait
It's waiting for lreq->reg_commit_wait to be completed, but for that to happen the respective request needs to end up on need_resend_linger list and be kicked when requests are unpaused. There is no chance for that if the request in question is never marked paused in the first place.
The fact that rbd_dev->watch_mutex remains taken out forever then prevents the image from getting unmapped -- "rbd unmap" would inevitably hang in D state on an attempt to grab the mutex.
Which versions are affected by CVE-2026-23047?
How do I fix CVE-2026-23047?
Apply the vendor's patch.
Upgrade, then put limits on request size, rate and nesting depth so one client cannot exhaust the service. More about Denial of service.
Is CVE-2026-23047 being exploited?
There is no known exploitation of CVE-2026-23047 in the wild and no public exploit code.
Sources
Also known as BELL-CVE-2026-23047, DEBIAN-CVE-2026-23047, GHSA-484m-2c5w-2g38, ROOT-OS-DEBIAN-11-CVE-2026-23047, ROOT-OS-DEBIAN-12-CVE-2026-23047, ROOT-OS-DEBIAN-13-CVE-2026-23047 and 2 more.