Subject: CVE-2023-52881: tcp: do not accept ACK of bytes we never sent

From: Greg Kroah-Hartman <[email-masked]>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

tcp: do not accept ACK of bytes we never sent

This patch is based on a detailed report and ideas from Yepeng Pan
and Christian Rossow.

ACK seq validation is currently following RFC 5961 5.2 guidelines:

   The ACK value is considered acceptable only if
   it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
   SND.NXT).  All incoming segments whose ACK value doesn't satisfy the
   above condition MUST be discarded and an ACK sent back.  It needs to
   be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
   duplicate (SEG.ACK < SND.UNA), it can be ignored.  If the ACK
   acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
   ACK, drop the segment, and return".  The "ignored" above implies that
   the processing of the incoming data segment continues, which means
   the ACK value is treated as acceptable.  This mitigation makes the
   ACK check more stringent since any ACK < SND.UNA wouldn't be
   accepted, instead only ACKs that are in the range ((SND.UNA -
   MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.

This can be refined for new (and possibly spoofed) flows,
by not accepting ACK for bytes that were never sent.

This greatly improves TCP security at a little cost.

I added a Fixes: tag to make sure this patch will reach stable trees,
even if the 'blamed' patch was adhering to the RFC.

tp->bytes_acked was added in linux-4.2

Following packetdrill test (courtesy of Yepeng Pan) shows
the issue at hand:

0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1024) = 0

// ---------------- Handshake ------------------- //

// when window scale is set to 14 the window size can be extended to
// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet
// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)
// ,though this ack number acknowledges some data never
// sent by the server.

+0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14>
+0 > S. 0:0(0) ack 1 <...>
+0 < . 1:1(0) ack 1 win 65535
+0 accept(3, ..., ...) = 4

// For the established connection, we send an ACK packet,
// the ack packet uses ack number 1 - 1073725300 + 2^32,
// where 2^32 is used to wrap around.
// Note: we used 1073725300 instead of 1073725440 to avoid possible
// edge cases.
// 1 - 1073725300 + 2^32 = 3221241997

// Oops, old kernels happily accept this packet.
+0 < . 1:1001(1000) ack 3221241997 win 65535

// After the kernel fix the following will be replaced by a challenge ACK,
// and prior malicious frame would be dropped.
+0 > . 1:1(0) ack 1001

The Linux kernel CVE team has assigned CVE-2023-52881 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 3.8 with commit 354e4aa391ed and fixed in 4.14.333 with commit 69eae75ca525
	Issue introduced in 3.8 with commit 354e4aa391ed and fixed in 4.19.302 with commit 458f07ffeccd
	Issue introduced in 3.8 with commit 354e4aa391ed and fixed in 5.4.264 with commit 7ffff0cc929f
	Issue introduced in 3.8 with commit 354e4aa391ed and fixed in 5.10.204 with commit b17a886ed29f
	Issue introduced in 3.8 with commit 354e4aa391ed and fixed in 5.15.143 with commit 0d4e0afdd665
	Issue introduced in 3.8 with commit 354e4aa391ed and fixed in 6.1.68 with commit 008b807fe487
	Issue introduced in 3.8 with commit 354e4aa391ed and fixed in 6.6.7 with commit 2087d53a66e9
	Issue introduced in 3.8 with commit 354e4aa391ed and fixed in 6.7 with commit 3d501dd326fb
	Issue introduced in 3.0.58 with commit 8d15569e14cf
	Issue introduced in 3.2.37 with commit e252bbd8c87b
	Issue introduced in 3.4.25 with commit 2ee4432e8243

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2023-52881
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	net/ipv4/tcp_input.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/69eae75ca5255e876628ac5cee9eaab31f644b57
	https://git.kernel.org/stable/c/458f07ffeccd17f99942311e09ef574ddf4a414a
	https://git.kernel.org/stable/c/7ffff0cc929fdfc62a74b384c4903d6496c910f0
	https://git.kernel.org/stable/c/b17a886ed29f3b70b78ccf632dad03e0c69e3c1a
	https://git.kernel.org/stable/c/0d4e0afdd6658cd21dd5be61880411a2553fd1fc
	https://git.kernel.org/stable/c/008b807fe487e0b15a3a6c39add4eb477f73e440
	https://git.kernel.org/stable/c/2087d53a66e97a5eb5d1bf558d5bef9e5f891757
	https://git.kernel.org/stable/c/3d501dd326fb1c73f1b8206d4c6e1d7b15c07e27