libceph: reject bad connect_seq in msgr1 READY reply

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 <ngocthang2710.1999@gmail.com>
Reviewed-by: Alex Markuze <amarkuze@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
This commit is contained in:
Nguyen Ngoc Thang 2026-10-02 07:06:17 +00:00 committed by Ilya Dryomov
parent 6c80207392
commit 6dfc1b1a99

View File

@ -887,6 +887,12 @@ static int process_connect(struct ceph_connection *con)
return -1;
}
if (le32_to_cpu(con->v1.in_reply.connect_seq) !=
con->v1.connect_seq + 1) {
con->error_msg = "protocol error, bad connect_seq";
return -1;
}
WARN_ON(con->state != CEPH_CON_S_V1_CONNECT_MSG);
con->state = CEPH_CON_S_OPEN;
con->v1.auth_retry = 0; /* we authenticated; clear flag */
@ -898,8 +904,6 @@ static int process_connect(struct ceph_connection *con)
con->v1.peer_global_seq,
le32_to_cpu(con->v1.in_reply.connect_seq),
con->v1.connect_seq);
WARN_ON(con->v1.connect_seq !=
le32_to_cpu(con->v1.in_reply.connect_seq));
if (con->v1.in_reply.flags & CEPH_MSG_CONNECT_LOSSY)
ceph_con_flag_set(con, CEPH_CON_F_LOSSYTX);