From: CJ <firefly0158@163.com>
To: idryomov@gmail.com, amarkuze@redhat.com, slava@dubeyko.com
Cc: ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [BUG] ceph: WARNING in ceph_con_v1_try_read on a malformed banner
Date: Mon, 14 Sep 2026 17:23:54 +0800 (CST) [thread overview]
Message-ID: <3b8d4918.8e95.1a09f3aef51.Coremail.firefly0158@163.com> (raw)
Hi,
I am reporting a WARNING in the ceph messenger v1 read path, triggered by a
syzkaller reproducer that plays a malformed ceph server. The issue is
reproducible with HEAD commit cee9395acd8043be0644b25c34bfa86623f2b935
(v7.3-rc1, Linux 7.3.0-rc1).
The reproducer opens a listening TCP socket on the loopback address, mounts ceph
through fsopen/fsconfig with source 127.0.0.1:6789:/, accepts the connection the
client makes, and then writes a banner followed by a short handshake message
with an inconsistent length field.
The WARNING fires in the ceph-msgr workqueue (Workqueue: ceph-msgr
ceph_con_workfn), not in the syscall task. The console shows a WARNING at
net/ceph/messenger_v1.c:901 with RIP in ceph_con_v1_try_read; in the original
report the same warning was attributed to the inlined process_connect path at
messenger_v1.c:911/912, which is the same handshake processing inside this
function.
One possible cause is that the length or tag field taken from the peer's
handshake message is not validated against the bytes actually received before it
is used, so a crafted server response drives the connection state machine
through an unexpected transition and trips the warning. This looks like missing
validation of untrusted peer input on the connect path. I am reporting the
warning and the path as observed.
This appears to be a recurrence of the syzbot issue whose external id is
7e30a4b55dcfeab9b21d. It remains reproducible on v7.3-rc1.
Reproducer:
syz reproducer:
r0 = socket$inet_tcp(0x2, 0x1, 0x0)
bind$inet(r0, &(0x7f0000000000)={0x2, 0x1a85, @loopback}, 0x10)
listen(r0, 0x5)
r1 = fsopen(&(0x7f0000000100)='ceph\x00', 0x0)
fsconfig$FSCONFIG_SET_STRING(r1, 0x1, &(0x7f0000000140)='source\x00', &(0x7f0000000180)='127.0.0.1:6789:/\x00', 0x0)
fsconfig$FSCONFIG_CMD_CREATE(r1, 0x6, 0x0, 0x0, 0x0)
r2 = accept$inet(r0, 0x0, 0x0)
write(r2, &(0x7f0000000300)='ceph v027\x00'/278, 0x119)
write(r2, &(0x7f0000000800)="01ffffffffffffffff00"/29, 0x1e)
console output: https://pastebin.com/raw/ErEPydDv
kernel config: https://pastebin.com/raw/wc2V1mqu
Kernel:
HEAD commit: cee9395acd8043be0644b25c34bfa86623f2b935
git tree: upstream (linux.git), tested through the v7.3-rc1 annotated tag object
e5e04726cdd043e309677071ab1b65a4b18f422b
kernel version: 7.3.0-rc1 #1 PREEMPT(full)
tested tag: v7.3-rc1 (Linux 7.3-rc1, 2026-08-30)
Let me know if you need more details or testing.
Best regards,
Changjian
reply other threads:[~2026-09-14 9:24 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3b8d4918.8e95.1a09f3aef51.Coremail.firefly0158@163.com \
--to=firefly0158@163.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®