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.
Reported-by: syzbot+21f8628595b2061c438d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=21f8628595b2061c438d
Fixes: 31b8006e10a4 ("ceph: messenger library")
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
---
net/ceph/messenger_v1.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/ceph/messenger_v1.c b/net/ceph/messenger_v1.c
index c9e002d96319..b3ff3274344e 100644
--- a/net/ceph/messenger_v1.c
+++ b/net/ceph/messenger_v1.c
@@ -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);
--
2.43.0