CVE-2026-23047: libceph: make calc_target() set t->paused, not just clear it
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.
Security readout for executives and security teams
Plain-English summary
This Linux kernel libceph/RBD bug can leave a Ceph block device watch unrecovered after request pause/unpause handling. The visible business impact is an availability problem: an affected RBD image may fail to unmap because the kernel path hangs waiting on a mutex.
Executive priority
Treat as medium priority for environments that depend on Ceph RBD availability. It is lower priority for general Linux fleets without Ceph kernel client use. The main risk is stuck storage operations requiring operational intervention.
Technical view
The flaw is in libceph calc_target() pause state handling for linger requests. Because linger requests were not marked paused, they could miss resend processing after unpause. The described consequence is rbd_reregister_watch() holding rbd_dev->watch_mutex indefinitely, causing rbd unmap to hang in D state.
Likely exposure
Exposure is mainly Linux systems using Ceph RBD/libceph, especially where RBD watches and request pause/unpause transitions occur. Systems not using Ceph RBD are unlikely to be exposed based on the supplied sources.
Exploitation context
The source bundle does not show KEV listing, public exploitation, exploit code, or remote attacker requirements. The described outcome is operational denial of service through a kernel hang condition, not data disclosure or code execution.
Researcher notes
The CVE description is detailed about root cause and failure mode, but lacks CVSS, CWE, exploitability analysis, and distribution package status. Avoid broad claims beyond Linux kernel libceph/RBD linger request pause handling.
Mitigation direction
Identify Linux hosts using Ceph RBD or kernel libceph clients.
Check whether your kernel includes one of the referenced stable fixes.
Prioritize updates for storage nodes, virtualization hosts, and Kubernetes nodes using RBD.
Consult Linux distribution advisories for backported package versions.
Plan maintenance for affected systems because kernel remediation usually requires reboot.
Validation and detection
Inventory hosts with mapped RBD images or Ceph kernel client usage.
Compare running kernel versions against vendor-fixed package guidance.
Review logs for RBD watch re-registration or unmap hangs.
Check for rbd unmap processes stuck in D state.
Confirm remediation by testing RBD map, watch recovery, and unmap behavior.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23047 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
8Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Feb 4, 2026, 16:00 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.