CVE-2023-52881
Last modified
CVE-2023-52881 is a medium-severity vulnerability rated 5.5/10 on the CVSS scale. 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. EPSS estimates a 0.23% chance of exploitation in the next 30 days.
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
Metrics
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Affected Software
| Vendor | Product | Versions | Update |
|---|---|---|---|
| Linux | Linux Kernel | >= 3.0.58, < 3.1 | — |
| Linux | Linux Kernel | >= 3.2.37, < 3.3 | — |
| Linux | Linux Kernel | >= 3.4.25, < 3.5 | — |
| Linux | Linux Kernel | >= 3.8, < 4.14.333 | — |
| Linux | Linux Kernel | >= 4.15, < 4.19.302 | — |
| Linux | Linux Kernel | >= 4.20, < 5.4.264 | — |
| Linux | Linux Kernel | >= 5.5, < 5.10.204 | — |
| Linux | Linux Kernel | >= 5.11, < 5.15.143 | — |
| Linux | Linux Kernel | >= 5.16, < 6.1.68 | — |
| Linux | Linux Kernel | >= 6.2, < 6.6.7 | — |
| Linux | Linux Kernel | 6.7 | Rc1 |
References
Timeline
- Published
- Last Modified
- Status
- Modified
Frequently Asked Questions
What is CVE-2023-52881?
How severe is CVE-2023-52881?
How do I fix CVE-2023-52881?
How Strix Helps
- How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
- Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
- PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
- AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.
Related CVEs from 2023
- CVE-2023-52876In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2023-52877In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2023-52878In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2023-52879In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2023-5288 A remote unauthorized attacker may connect to the SIM1012, …9.8
- CVE-2023-52880In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2023-52882In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2023-52883In the Linux kernel, the following vulnerability has been re…7.5
- CVE-2023-52884In the Linux kernel, the following vulnerability has been re…4.4
- CVE-2023-52885In the Linux kernel, the following vulnerability has been re…7.8
- CVE-2023-52886In the Linux kernel, the following vulnerability has been re…6.4
- CVE-2023-52887In the Linux kernel, the following vulnerability has been re…5.5
Are you affected by CVE-2023-52881?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
