In the Linux kernel, the following vulnerability has been resolved:
tcp: add sanity tests to TCPQUEUESEQ
Qingyu Li reported a syzkaller bug where the repro changes RCV SEQ after restoring data in the receive queue.
mprotect(0x4aa000, 12288, PROTREAD) = 0 mmap(0x1ffff000, 4096, PROTNONE, MAPPRIVATE|MAPFIXED|MAPANONYMOUS, -1, 0) = 0x1ffff000 mmap(0x20000000, 16777216, PROTREAD|PROTWRITE|PROTEXEC, MAPPRIVATE|MAPFIXED|MAPANONYMOUS, -1, 0) = 0x20000000 mmap(0x21000000, 4096, PROTNONE, MAPPRIVATE|MAPFIXED|MAPANONYMOUS, -1, 0) = 0x21000000 socket(AFINET6, SOCKSTREAM, IPPROTOIP) = 3 setsockopt(3, SOLTCP, TCPREPAIR, [1], 4) = 0 connect(3, {safamily=AFINET6, sin6port=htons(0), sin6flowinfo=htonl(0), inetpton(AFINET6, "::1", &sin6addr), sin6scopeid=0}, 28) = 0 setsockopt(3, SOLTCP, TCPREPAIRQUEUE, [1], 4) = 0 sendmsg(3, {msgname=NULL, msgnamelen=0, msgiov=[{iovbase="0x0000000000000003\0\0", iovlen=20}], msgiovlen=1, msgcontrollen=0, msgflags=0}, 0) = 20 setsockopt(3, SOLTCP, TCPREPAIR, [0], 4) = 0 setsockopt(3, SOLTCP, TCPQUEUE_SEQ, [128], 4) = 0 recvfrom(3, NULL, 20, 0, NULL, NULL) = -1 ECONNRESET (Connection reset by peer)
syslog shows: [ 111.205099] TCP recvmsg seq # bug 2: copied 80, seq 0, rcvnxt 80, fl 0 [ 111.207894] WARNING: CPU: 1 PID: 356 at net/ipv4/tcp.c:2343 tcprecvmsglocked+0x90e/0x29a0
This should not be allowed. TCPQUEUESEQ should only be used when queues are empty.
This patch fixes this case, and the tx path as well.