[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2026020440-CVE-2026-23047-38d4@gregkh>
Date: Wed, 4 Feb 2026 17:00:47 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2026-23047: libceph: make calc_target() set t->paused, not just clear it
From: Greg Kroah-Hartman <gregkh@...nel.org>
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.
The Linux kernel CVE team has assigned CVE-2026-23047 to this issue.
Affected and fixed versions
===========================
Fixed in 5.10.248 with commit 2b3329b3c29d9e188e40d902d5230c2d5989b940
Fixed in 5.15.198 with commit 5d0dc83cb9a69c1d0bea58f1c430199b05f6b021
Fixed in 6.1.161 with commit 4d3399c52e0e61720ae898f5a0b5b75d4460ae24
Fixed in 6.6.121 with commit 4ebc711b738d139cabe2fc9e7e7749847676a342
Fixed in 6.12.66 with commit 6f468f6ff233c6a81e0e761d9124e982903fe9a5
Fixed in 6.18.6 with commit 5647d42c47b535573b63e073e91164d6a5bb058c
Fixed in 6.19-rc5 with commit c0fe2994f9a9d0a2ec9e42441ea5ba74b6a16176
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-23047
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
net/ceph/osd_client.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/2b3329b3c29d9e188e40d902d5230c2d5989b940
https://git.kernel.org/stable/c/5d0dc83cb9a69c1d0bea58f1c430199b05f6b021
https://git.kernel.org/stable/c/4d3399c52e0e61720ae898f5a0b5b75d4460ae24
https://git.kernel.org/stable/c/4ebc711b738d139cabe2fc9e7e7749847676a342
https://git.kernel.org/stable/c/6f468f6ff233c6a81e0e761d9124e982903fe9a5
https://git.kernel.org/stable/c/5647d42c47b535573b63e073e91164d6a5bb058c
https://git.kernel.org/stable/c/c0fe2994f9a9d0a2ec9e42441ea5ba74b6a16176
Powered by blists - more mailing lists