linux-toradex.git/net/ceph, branch master

Merge tag 'ceph-for-7.4-rc1' of https://github.com/ceph/ceph-client

2026-10-30T19:42:10+00:00

Pull ceph updates from Ilya Dryomov:
 "The two things of note here are the disablement of inline data support
  and a new lazyio mount option to enable LAZYIO behavior globally
  (instead of via an ioctl on a per-file basis), both from Xiubo.

  Despite being over a decade old, the inline data feature never lost
  its experimental status -- it has always been off by default and
  required passing --yes-i-really-mean-it flag to be turned on. It was
  officially deprecated in 2020 and is now in the process of being
  removed on the MDS side. For now it's still possible to re-enable it
  in Kconfig, but the code will eventually be dropped from the kernel
  client entirely.

  Outside of that we have a number of bug fixes, a series from Tal to
  help phase out older page APIs, some cleanups from Max and a large
  pile of LLM-based hardening patches.

  Xiubo is also back in a maintainer role, replacing Slava"

* tag 'ceph-for-7.4-rc1' of https://github.com/ceph/ceph-client: (66 commits)
  ceph: fix uninitialized err in ceph_netfs_issue_read()
  MAINTAINERS: update ceph and libceph maintainers
  ceph: validate encoded xattr name lengths
  ceph: validate MDS reply fragtree split array length
  ceph: bound name skips in ceph_mdsmap_decode() by the message end
  ceph: validate fscrypt auth blob length
  ceph: check the caps of a closed file after caps_wanted_delay_min
  ceph: don't fail write_begin with -EAGAIN after flushing old snapc
  ceph: fail readdir when the MDS reply carries no dirfrag
  ceph: clamp MDS reply result code to the errno range
  libceph: initialize CRUSH choose argument weights
  libceph: fix out-of-bounds reads from repeated CRUSH bucket entries
  ceph: fix 32-bit overflow in readdir reply count check
  libceph: reject bad connect_seq in msgr1 READY reply
  ceph: Fix mds session leak in __open_export_target_session()
  ceph: Fix xattr buffer leak in __send_cap()
  ceph: fix integer overflow in the snap trace bounds check
  libceph: bound mon_command ack decode to front len
  ceph: use alloc_page() in fill_fscrypt_truncate()
  libceph: use alloc_page() in ceph_alloc_page_vector()
  ...

libceph: initialize CRUSH choose argument weights

2026-10-26T13:15:47+00:00

Initialize the CRUSH choose argument weight-set array before decoding so
entries start in a defined state while the decoder fills them.

Cc: stable@vger.kernel.org
Fixes: 5cf9c4a9959b ("libceph, crush: per-pool crush_choose_arg_map for crush_do_rule()")
Reported-by: Vega 
Assisted-by: LLM
Signed-off-by: Darong Lu 
Signed-off-by: Ren Wei 
Reviewed-by: Alex Markuze 
Signed-off-by: Ilya Dryomov

libceph: fix out-of-bounds reads from repeated CRUSH bucket entries

2026-10-26T13:15:47+00:00

decode_choose_arg() assumes that its destination is zero-initialized.
Although decode_choose_args() zeroes the argument array, it does not reject
a repeated bucket_index and can decode into an already populated entry.

Repeating a bucket with weight_set_size=0 preserves its existing weight_set
pointer but clears the count. Placement then reads weight_set[-1].weights
and dereferences the resulting pointer.

A malformed monitor OSDMap triggers this during RBD placement:

  BUG: KASAN: slab-out-of-bounds in crush_bucket_choose+0xdd1/0xf90
  Read of size 8 at addr ffff88800290df70 by task init/75

Reject populated arguments before decoding another entry, so the error
path can free their original allocations.

Cc: stable@vger.kernel.org
Fixes: c7ed1a4bf4b4 ("crush: assume weight_set != null imples weight_set_size > 0")
Assisted-by: Codex:gpt-5
Signed-off-by: Jérémy Jean 
Reviewed-by: Alex Markuze 
Signed-off-by: Ilya Dryomov

libceph: reject bad connect_seq in msgr1 READY reply

2026-10-26T13:15:47+00:00

process_connect() WARN_ON()s when the peer's READY/SEQ reply carries a
connect_seq other than ours + 1. That value comes off the wire, so a
misbehaving or malicious server can trigger the warning at will (and
panic machines running with panic_on_warn).

Check it before touching connection state and fail the connection with
a protocol error instead, like the other bad-reply cases here.

Fixes: 31b8006e10a4 ("ceph: messenger library")
Reported-by: syzbot+21f8628595b2061c438d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=21f8628595b2061c438d
Signed-off-by: Nguyen Ngoc Thang 
Reviewed-by: Alex Markuze 
Signed-off-by: Ilya Dryomov

libceph: bound mon_command ack decode to front len

2026-10-26T13:15:47+00:00

handle_command_ack() bounds the decode with msg->front_alloc_len, the size
of the reply buffer, instead of msg->front.iov_len, the number of bytes the
monitor sent.  mon_alloc_msg() routes every CEPH_MSG_MON_COMMAND_ACK to
get_generic_reply(), which returns the preallocated ->reply of whichever
generic request carries the same tid, so the buffer keeps its fixed size
however short the reply is.  An ack with hdr.front_len below sizeof(struct
ceph_mon_request_header) + sizeof(u32), including 0, still passes
ceph_decode_need(), and ceph_decode_32() returns four bytes that were never
received: uninitialized slab memory, stale bytes of an earlier message, or
bytes the peer planted by sending a reply that lands in the same buffer and
is then rejected.  The read stays within the allocation, so KASAN does not
flag it.

req->result reaches userspace through ceph_monc_do_statfs(),
ceph_monc_get_version() and ceph_monc_blocklist_add(); rbd hands it back
from write() on /sys/bus/rbd/add_single_major, and rbd_get_client() passes
it to ERR_PTR() unchecked, which faults:

  rbd: failed to get latest osdmap: -186318427
  BUG: unable to handle page fault for address: fffffbfffe9ca034
  Oops: Oops: 0000 [#1] SMP KASAN NOPTI
  RIP: 0010:do_rbd_add (drivers/block/rbd.c:7105)
  Call Trace:
   ...
   kernfs_fop_write_iter (fs/kernfs/file.c:345)
   vfs_write (fs/read_write.c:595 fs/read_write.c:687)
   ksys_write (fs/read_write.c:739)
   do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84)
   entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
  Kernel panic - not syncing: Fatal exception

Use msg->front.iov_len, matching handle_subscribe_ack(),
handle_statfs_reply(), handle_get_version_reply() and handle_auth_reply().
A well-formed ack has front.iov_len >= 22 and is unaffected; a short one
takes the existing bad: path.  This applies commit d3c32939fa0e ("libceph:
bound get_version reply decode to front len") to the last decode-side
use of front_alloc_len in this file.

Cc: stable@vger.kernel.org
Fixes: 6305a3b41515 ("libceph: support for blacklisting clients")
Reported-by: co+25860fb17af97289@bugs.sh
Assisted-by: Cursor
Signed-off-by: Xiang Mei 
Reviewed-by: Alex Markuze 
Signed-off-by: Ilya Dryomov

libceph: use alloc_page() in ceph_alloc_page_vector()

2026-10-26T13:15:47+00:00

ceph_alloc_page_vector() allocates its pages with __page_cache_alloc().
However, the pages are never inserted into an address_space and do not
need the cpuset memory spread policy __page_cache_alloc() provides. Use
alloc_page() instead.

Assisted-by: Cursor
Signed-off-by: Tal Zussman 
Reviewed-by: Alex Markuze 
Signed-off-by: Ilya Dryomov

libceph: reject an initial monmap with no monitors

2026-10-26T13:15:47+00:00

build_initial_monmap() takes the monitor count straight from
ceph_options::num_mon and builds a monmap with that many entries without
checking that there is at least one. ceph_parse_ips() writes *count only
after it has parsed an address successfully, so a ceph_options that went
through a failed parse still has num_mon == 0 and the resulting monmap
has no monitors in it at all.

The first thing the client does with that monmap is open a session, and
pick_new_mon() asserts the invariant that it is non-empty:

  kernel BUG at net/ceph/mon_client.c:211!
  RIP: 0010:pick_new_mon net/ceph/mon_client.c:211 [inline]
  RIP: 0010:__open_session+0x60f/0x740 net/ceph/mon_client.c:245
  Call Trace:
   ceph_monc_open_session+0x46/0x60 net/ceph/mon_client.c:534
   __ceph_open_session+0x135/0x590 net/ceph/ceph_common.c:798
   ceph_real_mount fs/ceph/super.c:1173 [inline]
   ceph_get_tree+0xd98/0x1fd0 fs/ceph/super.c:1362
   vfs_get_tree+0x92/0x320 fs/super.c:1947
   vfs_cmd_create+0xd7/0x2a0 fs/fsopen.c:231
   __do_sys_fsconfig+0x55a/0xcb0 fs/fsopen.c:463

The reproducer gets there through the new device syntax: an fsconfig()
mon_addr= that does not resolve ("libceph: resolve '127.0.0.' (ret=-3):
failed") leaves fsopt->mon_addr set but num_mon at 0, so the "No monitor
address" check in ceph_get_tree() passes and the mount proceeds with an
empty monmap. The next patch stops that string from being kept, but the
assertion should not be reachable from a mount option in the first place.

Commit 40480eee361e ("libceph: Reject monmaps advertising zero monitors")
made the same BUG_ON() unreachable from the wire by rejecting
num_mon == 0 in ceph_monmap_decode(). Apply the same rule to the initial
monmap, which is the only other way one gets built, and fail the mount
with -EINVAL rather than assert afterwards.

Cc: stable@vger.kernel.org
Fixes: 7b19b4db5add ("ceph: new device mount syntax")
Reported-by: syzbot+1dbed5969931c19d3eb5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1dbed5969931c19d3eb5
Assisted-by: Cursor
Signed-off-by: Yogesh Gaur 
Reviewed-by: Alex Markuze 
Signed-off-by: Ilya Dryomov

libceph: reject mismatched CRUSH weight-set sizes

2026-10-26T13:15:47+00:00

A CEPH_MSG_OSD_MAP message can contain CRUSH choose args with replacement
weight vectors for straw2 buckets.  decode_choose_args() validates the
optional IDs vector against the referenced bucket, but does not validate
the size of any replacement-weight vector.

The CRUSH mapper assumes that each replacement vector has exactly as many
entries as the bucket.  A zero-length vector for a nonempty bucket makes
bucket_straw2_choose() dereference NULL, while a shorter nonzero vector
causes an out-of-bounds read.  An authenticated monitor or OSD can deliver
such a map and crash a kernel client when it performs placement for an
ordinary request.

Reject a nonempty collection of weight sets for an absent bucket and
require every replacement-weight vector to match its bucket size.

Cc: stable@vger.kernel.org
Fixes: 5cf9c4a9959b ("libceph, crush: per-pool crush_choose_arg_map for crush_do_rule()")
Assisted-by: Codex:gpt-5
Signed-off-by: Felix Hoffmann 
Reviewed-by: Alex Markuze 
Signed-off-by: Ilya Dryomov

libceph: Fix multiple unsafe decodes in ceph_oloc_decode()

2026-10-26T13:15:47+00:00

ceph_oloc_decode handles unchecked data received over the network from
an OSD. Currently, there are multiple decode operations that aren't
covered by any bounds check. Decoding these fields can therefore result
in out-of-bounds reads if a corrupted message is received.

This patch fixes the issue by adding bounds checks covering all
previously uncovered decode operations.

[ idryomov: use ceph_decode_64_safe() for hash ]

Cc: stable@vger.kernel.org
Fixes: 205ee1187a67 ("libceph: follow redirect replies from osds")
Assisted-by: Cursor
Signed-off-by: Raphael Zimmer 
Reviewed-by: Alex Markuze 
Signed-off-by: Ilya Dryomov

libceph: Fix unsafe decode in ceph_redirect_decode()

2026-10-26T13:15:47+00:00

ceph_redirect_decode handles unchecked data received over the network
from an OSD. Currently, there is only a bounds check covering the first
three decode operations. After decoding the first len field from the
message, the only remaining check ensures there is enough buffer space
to hold len bytes. However, there is no guarantee that this value is
large enough to hold the subsequently decoded fields. The decoding of
the second len field is missing an explicit bounds check. Consequently,
a corrupted message can trigger an out-of-bounds read.

This patch fixes the issue by switching the decoding from
ceph_decode_32() to the bounds-checked version ceph_decode_32_safe().

Cc: stable@vger.kernel.org
Fixes: 205ee1187a67 ("libceph: follow redirect replies from osds")
Assisted-by: Cursor
Signed-off-by: Raphael Zimmer 
Reviewed-by: Alex Markuze 
Signed-off-by: Ilya Dryomov