From: Yogesh Gaur <yogeshgaur.83@gmail.com>
To: Ilya Dryomov <idryomov@gmail.com>, Alex Markuze <amarkuze@redhat.com>
Cc: Viacheslav Dubeyko <slava@dubeyko.com>,
ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
Yogesh Gaur <yogeshgaur.83@gmail.com>
Subject: [PATCH 0/2] ceph: don't let a bad mon_addr= reach the empty-monmap BUG_ON()
Date: Fri, 11 Sep 2026 19:01:08 +0530 [thread overview]
Message-ID: <20260911133110.2218-1-yogeshgaur.83@gmail.com> (raw)
syzbot can panic the kernel from fsconfig(2) by mounting cephfs with a
mon_addr= that does not parse:
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
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_cmd_create+0xd7/0x2a0 fs/fsopen.c:231
__do_sys_fsconfig+0x55a/0xcb0 fs/fsopen.c:463
https://syzkaller.appspot.com/bug?extid=1dbed5969931c19d3eb5
The sequence is fsopen("ceph"), fsconfig(FSCONFIG_SET_STRING, "mon_addr",
<something that does not resolve>) - which returns an error that the
caller simply ignores - and then FSCONFIG_CMD_CREATE. Two things have to
be true for that to end in a BUG():
1/ ceph_parse_mon_addr() commits the string to fsopt->mon_addr before
validating it, so the rejected value survives the failed fsconfig()
and satisfies ceph_get_tree()'s "No monitor address" check.
2/ ceph_parse_ips() never got as far as writing *count, so num_mon stays
0, and build_initial_monmap() happily builds a monmap with no
monitors in it. pick_new_mon() then trips its own invariant.
Patch 1 closes 2/ in libceph, which is what actually stops the BUG().
It is the same rule commit 40480eee361e ("libceph: Reject monmaps
advertising zero monitors") applied to monmaps arriving from the wire,
now applied to the one built locally from mount options. Patch 2 closes
1/ so the bad string is not kept in the first place and the failure is
reported where it happens.
Either patch on its own stops the reported crash; I think both are worth
having, but say the word and I will send just the first.
Compile-tested only: x86_64 defconfig + CONFIG_CEPH_LIB=m +
CONFIG_CEPH_FS=m, net/ceph/mon_client.o and fs/ceph/super.o both W=1
clean, checkpatch --strict clean on both patches. I have no ceph cluster
here and did not run the syzbot reproducer, so this is reasoning from the
code and the report, not an observed fix - please treat it accordingly.
Yogesh Gaur (2):
libceph: reject an initial monmap with no monitors
ceph: don't keep a mon_addr= that failed to parse
fs/ceph/super.c | 9 +++++++--
net/ceph/mon_client.c | 3 +++
2 files changed, 10 insertions(+), 2 deletions(-)
--
2.55.0.windows.5
next reply other threads:[~2026-09-11 13:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 13:31 Yogesh Gaur [this message]
2026-09-11 13:31 ` [PATCH 1/2] libceph: reject an initial monmap with no monitors Yogesh Gaur
2026-09-11 13:31 ` [PATCH 2/2] ceph: don't keep a mon_addr= that failed to parse Yogesh Gaur
2026-09-22 11:15 ` [PATCH 0/2] ceph: don't let a bad mon_addr= reach the empty-monmap BUG_ON() Alex Markuze
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260911133110.2218-1-yogeshgaur.83@gmail.com \
--to=yogeshgaur.83@gmail.com \
--cc=amarkuze@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=slava@dubeyko.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.