<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/net/ceph, branch linux-5.10.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.10.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.10.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2026-01-19T12:12:08Z</updated>
<entry>
<title>libceph: make calc_target() set t-&gt;paused, not just clear it</title>
<updated>2026-01-19T12:12:08Z</updated>
<author>
<name>Ilya Dryomov</name>
</author>
<published>2026-01-05T18:23:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2b3329b3c29d9e188e40d902d5230c2d5989b940'/>
<id>urn:sha1:2b3329b3c29d9e188e40d902d5230c2d5989b940</id>
<content type='text'>
commit c0fe2994f9a9d0a2ec9e42441ea5ba74b6a16176 upstream.

Currently calc_target() clears t-&gt;paused if the request shouldn't be
paused anymore, but doesn't ever set t-&gt;paused even though it's able to
determine when the request should be paused.  Setting t-&gt;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-&gt;t.paused to be set.
One consequence of this is that watches don't get reestablished on
paused -&gt; 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-&gt;watch_mutex held:

  rbd_register_watch
    __rbd_register_watch
      ceph_osdc_watch
        linger_reg_commit_wait

It's waiting for lreq-&gt;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-&gt;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.

Cc: stable@vger.kernel.org
Reported-by: Raphael Zimmer &lt;raphael.zimmer@tu-ilmenau.de&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Reviewed-by: Viacheslav Dubeyko &lt;Slava.Dubeyko@ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>libceph: make free_choose_arg_map() resilient to partial allocation</title>
<updated>2026-01-19T12:12:08Z</updated>
<author>
<name>Tuo Li</name>
</author>
<published>2025-12-20T18:11:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9b3730dabcf3764bfe3ff07caf55e641a0b45234'/>
<id>urn:sha1:9b3730dabcf3764bfe3ff07caf55e641a0b45234</id>
<content type='text'>
commit e3fe30e57649c551757a02e1cad073c47e1e075e upstream.

free_choose_arg_map() may dereference a NULL pointer if its caller fails
after a partial allocation.

For example, in decode_choose_args(), if allocation of arg_map-&gt;args
fails, execution jumps to the fail label and free_choose_arg_map() is
called. Since arg_map-&gt;size is updated to a non-zero value before memory
allocation, free_choose_arg_map() will iterate over arg_map-&gt;args and
dereference a NULL pointer.

To prevent this potential NULL pointer dereference and make
free_choose_arg_map() more resilient, add checks for pointers before
iterating.

Cc: stable@vger.kernel.org
Co-authored-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Tuo Li &lt;islituo@gmail.com&gt;
Reviewed-by: Viacheslav Dubeyko &lt;Slava.Dubeyko@ibm.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>libceph: replace overzealous BUG_ON in osdmap_apply_incremental()</title>
<updated>2026-01-19T12:12:08Z</updated>
<author>
<name>Ilya Dryomov</name>
</author>
<published>2025-12-15T10:53:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9aa0b0c14cefece078286d78b97d4c09685e372d'/>
<id>urn:sha1:9aa0b0c14cefece078286d78b97d4c09685e372d</id>
<content type='text'>
commit e00c3f71b5cf75681dbd74ee3f982a99cb690c2b upstream.

If the osdmap is (maliciously) corrupted such that the incremental
osdmap epoch is different from what is expected, there is no need to
BUG.  Instead, just declare the incremental osdmap to be invalid.

Cc: stable@vger.kernel.org
Reported-by: ziming zhang &lt;ezrakiez@gmail.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>libceph: make decode_pool() more resilient against corrupted osdmaps</title>
<updated>2026-01-19T12:11:50Z</updated>
<author>
<name>Ilya Dryomov</name>
</author>
<published>2025-12-02T09:32:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d061be4c8040ffb1110d537654a038b8b6ad39d2'/>
<id>urn:sha1:d061be4c8040ffb1110d537654a038b8b6ad39d2</id>
<content type='text'>
commit 8c738512714e8c0aa18f8a10c072d5b01c83db39 upstream.

If the osdmap is (maliciously) corrupted such that the encoded length
of ceph_pg_pool envelope is less than what is expected for a particular
encoding version, out-of-bounds reads may ensue because the only bounds
check that is there is based on that length value.

This patch adds explicit bounds checks for each field that is decoded
or skipped.

Cc: stable@vger.kernel.org
Reported-by: ziming zhang &lt;ezrakiez@gmail.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Reviewed-by: Xiubo Li &lt;xiubli@redhat.com&gt;
Tested-by: ziming zhang &lt;ezrakiez@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>libceph: fix potential use-after-free in have_mon_and_osd_map()</title>
<updated>2025-12-06T21:08:24Z</updated>
<author>
<name>Ilya Dryomov</name>
</author>
<published>2025-11-03T20:34:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bb4910c5fd436701faf367e1b5476a5a6d2aff1c'/>
<id>urn:sha1:bb4910c5fd436701faf367e1b5476a5a6d2aff1c</id>
<content type='text'>
commit 076381c261374c587700b3accf410bdd2dba334e upstream.

The wait loop in __ceph_open_session() can race with the client
receiving a new monmap or osdmap shortly after the initial map is
received.  Both ceph_monc_handle_map() and handle_one_map() install
a new map immediately after freeing the old one

    kfree(monc-&gt;monmap);
    monc-&gt;monmap = monmap;

    ceph_osdmap_destroy(osdc-&gt;osdmap);
    osdc-&gt;osdmap = newmap;

under client-&gt;monc.mutex and client-&gt;osdc.lock respectively, but
because neither is taken in have_mon_and_osd_map() it's possible for
client-&gt;monc.monmap-&gt;epoch and client-&gt;osdc.osdmap-&gt;epoch arms in

    client-&gt;monc.monmap &amp;&amp; client-&gt;monc.monmap-&gt;epoch &amp;&amp;
        client-&gt;osdc.osdmap &amp;&amp; client-&gt;osdc.osdmap-&gt;epoch;

condition to dereference an already freed map.  This happens to be
reproducible with generic/395 and generic/397 with KASAN enabled:

    BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70
    Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305
    CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266
    ...
    Call Trace:
    &lt;TASK&gt;
    have_mon_and_osd_map+0x56/0x70
    ceph_open_session+0x182/0x290
    ceph_get_tree+0x333/0x680
    vfs_get_tree+0x49/0x180
    do_new_mount+0x1a3/0x2d0
    path_mount+0x6dd/0x730
    do_mount+0x99/0xe0
    __do_sys_mount+0x141/0x180
    do_syscall_64+0x9f/0x100
    entry_SYSCALL_64_after_hwframe+0x76/0x7e
    &lt;/TASK&gt;

    Allocated by task 13305:
    ceph_osdmap_alloc+0x16/0x130
    ceph_osdc_init+0x27a/0x4c0
    ceph_create_client+0x153/0x190
    create_fs_client+0x50/0x2a0
    ceph_get_tree+0xff/0x680
    vfs_get_tree+0x49/0x180
    do_new_mount+0x1a3/0x2d0
    path_mount+0x6dd/0x730
    do_mount+0x99/0xe0
    __do_sys_mount+0x141/0x180
    do_syscall_64+0x9f/0x100
    entry_SYSCALL_64_after_hwframe+0x76/0x7e

    Freed by task 9475:
    kfree+0x212/0x290
    handle_one_map+0x23c/0x3b0
    ceph_osdc_handle_map+0x3c9/0x590
    mon_dispatch+0x655/0x6f0
    ceph_con_process_message+0xc3/0xe0
    ceph_con_v1_try_read+0x614/0x760
    ceph_con_workfn+0x2de/0x650
    process_one_work+0x486/0x7c0
    process_scheduled_works+0x73/0x90
    worker_thread+0x1c8/0x2a0
    kthread+0x2ec/0x300
    ret_from_fork+0x24/0x40
    ret_from_fork_asm+0x1a/0x30

Rewrite the wait loop to check the above condition directly with
client-&gt;monc.mutex and client-&gt;osdc.lock taken as appropriate.  While
at it, improve the timeout handling (previously mount_timeout could be
exceeded in case wait_event_interruptible_timeout() slept more than
once) and access client-&gt;auth_err under client-&gt;monc.mutex to match
how it's set in finish_auth().

monmap_show() and osdmap_show() now take the respective lock before
accessing the map as well.

Cc: stable@vger.kernel.org
Reported-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Reviewed-by: Viacheslav Dubeyko &lt;Slava.Dubeyko@ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>libceph: fix race between delayed_work() and ceph_monc_stop()</title>
<updated>2024-07-18T11:05:49Z</updated>
<author>
<name>Ilya Dryomov</name>
</author>
<published>2024-07-08T20:37:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=34b76d1922e41da1fa73d43b764cddd82ac9733c'/>
<id>urn:sha1:34b76d1922e41da1fa73d43b764cddd82ac9733c</id>
<content type='text'>
commit 69c7b2fe4c9cc1d3b1186d1c5606627ecf0de883 upstream.

The way the delayed work is handled in ceph_monc_stop() is prone to
races with mon_fault() and possibly also finish_hunting().  Both of
these can requeue the delayed work which wouldn't be canceled by any of
the following code in case that happens after cancel_delayed_work_sync()
runs -- __close_session() doesn't mess with the delayed work in order
to avoid interfering with the hunting interval logic.  This part was
missed in commit b5d91704f53e ("libceph: behave in mon_fault() if
cur_mon &lt; 0") and use-after-free can still ensue on monc and objects
that hang off of it, with monc-&gt;auth and monc-&gt;monmap being
particularly susceptible to quickly being reused.

To fix this:

- clear monc-&gt;cur_mon and monc-&gt;hunting as part of closing the session
  in ceph_monc_stop()
- bail from delayed_work() if monc-&gt;cur_mon is cleared, similar to how
  it's done in mon_fault() and finish_hunting() (based on monc-&gt;hunting)
- call cancel_delayed_work_sync() after the session is closed

Cc: stable@vger.kernel.org
Link: https://tracker.ceph.com/issues/66857
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Reviewed-by: Xiubo Li &lt;xiubli@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>libceph: use kernel_connect()</title>
<updated>2023-10-25T09:54:15Z</updated>
<author>
<name>Jordan Rife</name>
</author>
<published>2023-10-04T23:38:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=62f6d24f2e7d6dee31eca8027543f264a4352a31'/>
<id>urn:sha1:62f6d24f2e7d6dee31eca8027543f264a4352a31</id>
<content type='text'>
commit 7563cf17dce0a875ba3d872acdc63a78ea344019 upstream.

Direct calls to ops-&gt;connect() can overwrite the address parameter when
used in conjunction with BPF SOCK_ADDR hooks. Recent changes to
kernel_connect() ensure that callers are insulated from such side
effects. This patch wraps the direct call to ops-&gt;connect() with
kernel_connect() to prevent unexpected changes to the address passed to
ceph_tcp_connect().

This change was originally part of a larger patch targeting the net tree
addressing all instances of unprotected calls to ops-&gt;connect()
throughout the kernel, but this change was split up into several patches
targeting various trees.

Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/netdev/20230821100007.559638-1-jrife@google.com/
Link: https://lore.kernel.org/netdev/9944248dba1bce861375fcce9de663934d933ba9.camel@redhat.com/
Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect")
Signed-off-by: Jordan Rife &lt;jrife@google.com&gt;
Reviewed-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>libceph, rbd: ignore addr-&gt;type while comparing in some cases</title>
<updated>2023-08-30T14:23:11Z</updated>
<author>
<name>Ilya Dryomov</name>
</author>
<published>2020-11-25T13:41:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=145248ebe0b2164f7d383cc942ec45fbd3c4b1a0'/>
<id>urn:sha1:145248ebe0b2164f7d383cc942ec45fbd3c4b1a0</id>
<content type='text'>
[ Upstream commit 313771e80fd253d4b5472e61a2d12b03c5293aa9 ]

For libceph, this ensures that libceph instance sharing (share option)
continues to work.  For rbd, this avoids blocklisting alive lock owners
(locker addr is always LEGACY, while watcher addr is ANY in nautilus).

Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Stable-dep-of: 588159009d5b ("rbd: retrieve and check lock owner twice before blocklisting")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>libceph: fix potential hang in ceph_osdc_notify()</title>
<updated>2023-08-11T09:57:51Z</updated>
<author>
<name>Ilya Dryomov</name>
</author>
<published>2023-08-01T17:14:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=513bfdde8a3b58cdfac37083c38f7b0100f72ae6'/>
<id>urn:sha1:513bfdde8a3b58cdfac37083c38f7b0100f72ae6</id>
<content type='text'>
commit e6e2843230799230fc5deb8279728a7218b0d63c upstream.

If the cluster becomes unavailable, ceph_osdc_notify() may hang even
with osd_request_timeout option set because linger_notify_finish_wait()
waits for MWatchNotify NOTIFY_COMPLETE message with no associated OSD
request in flight -- it's completely asynchronous.

Introduce an additional timeout, derived from the specified notify
timeout.  While at it, switch both waits to killable which is more
correct.

Cc: stable@vger.kernel.org
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Reviewed-by: Dongsheng Yang &lt;dongsheng.yang@easystack.cn&gt;
Reviewed-by: Xiubo Li &lt;xiubli@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>libceph: fix potential use-after-free on linger ping and resends</title>
<updated>2022-05-25T07:17:56Z</updated>
<author>
<name>Ilya Dryomov</name>
</author>
<published>2022-05-14T10:16:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8ceca1a0693a314712e7b1b727795b7be55f32e9'/>
<id>urn:sha1:8ceca1a0693a314712e7b1b727795b7be55f32e9</id>
<content type='text'>
commit 75dbb685f4e8786c33ddef8279bab0eadfb0731f upstream.

request_reinit() is not only ugly as the comment rightfully suggests,
but also unsafe.  Even though it is called with osdc-&gt;lock held for
write in all cases, resetting the OSD request refcount can still race
with handle_reply() and result in use-after-free.  Taking linger ping
as an example:

    handle_timeout thread                     handle_reply thread

                                              down_read(&amp;osdc-&gt;lock)
                                              req = lookup_request(...)
                                              ...
                                              finish_request(req)  # unregisters
                                              up_read(&amp;osdc-&gt;lock)
                                              __complete_request(req)
                                                linger_ping_cb(req)

      # req-&gt;r_kref == 2 because handle_reply still holds its ref

    down_write(&amp;osdc-&gt;lock)
    send_linger_ping(lreq)
      req = lreq-&gt;ping_req  # same req
      # cancel_linger_request is NOT
      # called - handle_reply already
      # unregistered
      request_reinit(req)
        WARN_ON(req-&gt;r_kref != 1)  # fires
        request_init(req)
          kref_init(req-&gt;r_kref)

                   # req-&gt;r_kref == 1 after kref_init

                                              ceph_osdc_put_request(req)
                                                kref_put(req-&gt;r_kref)

            # req-&gt;r_kref == 0 after kref_put, req is freed

        &lt;further req initialization/use&gt; !!!

This happens because send_linger_ping() always (re)uses the same OSD
request for watch ping requests, relying on cancel_linger_request() to
unregister it from the OSD client and rip its messages out from the
messenger.  send_linger() does the same for watch/notify registration
and watch reconnect requests.  Unfortunately cancel_request() doesn't
guarantee that after it returns the OSD client would be completely done
with the OSD request -- a ref could still be held and the callback (if
specified) could still be invoked too.

The original motivation for request_reinit() was inability to deal with
allocation failures in send_linger() and send_linger_ping().  Switching
to using osdc-&gt;req_mempool (currently only used by CephFS) respects that
and allows us to get rid of request_reinit().

Cc: stable@vger.kernel.org
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Reviewed-by: Xiubo Li &lt;xiubli@redhat.com&gt;
Acked-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
