CVE-2026-23047: In the Linux kernel, the following vulnerability has been resolved: libceph: make calc_target() set t->paused, not just clear it Currently calc_targ...

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.

Metrics

EPSS Probability

0.16%

5.7th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
Linux	Linux	>= 922dab6134178cae317ae00de86376cba59f3147, < 2b3329b3c29d9e188e40d902d5230c2d5989b940; >= 922dab6134178cae317ae00de86376cba59f3147, < 5d0dc83cb9a69c1d0bea58f1c430199b05f6b021; >= 922dab6134178cae317ae00de86376cba59f3147, < 4d3399c52e0e61720ae898f5a0b5b75d4460ae24; >= 922dab6134178cae317ae00de86376cba59f3147, < 4ebc711b738d139cabe2fc9e7e7749847676a342; >= 922dab6134178cae317ae00de86376cba59f3147, < 6f468f6ff233c6a81e0e761d9124e982903fe9a5; >= 922dab6134178cae317ae00de86376cba59f3147, < 5647d42c47b535573b63e073e91164d6a5bb058c; >= 922dab6134178cae317ae00de86376cba59f3147, < c0fe2994f9a9d0a2ec9e42441ea5ba74b6a16176
Linux	Linux	4.7

References

Timeline

Published: Feb 4, 2026
Last Modified: Jun 17, 2026
Status: Deferred

Frequently Asked Questions

What is CVE-2026-23047?

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.

How severe is CVE-2026-23047?

Severity scoring for CVE-2026-23047 is pending analysis. The EPSS model estimates a 0.16% probability of exploitation in the next 30 days.

How do I fix CVE-2026-23047?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →