tcp: do not accept ACK of bytes we never sent
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(.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 4.14.333, 4.19.302, 5.10.204, 5.15.143, 5.4.264, 6.1.68, 6.6.7
- CVEs
- CVE-2023-52881
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 08:42 UTC · Revision 1
Source evidence
tcp: do not accept ACK of bytes we never sent
core-osv · Original sourcePublished 29 May 2024, 10:15 UTC
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(.
osv:CVE-2023-52881
Kernel
Fixed versions: 4.14.333, 4.19.302, 5.4.264, 5.10.204, 5.15.143, 6.1.68, 6.6.7
Complete source record
{
"id": "a8d698018caa141534d3dfa8efd657a6af567aac677d5314eb73585bdf3ba504",
"url": "https://osv.dev/vulnerability/CVE-2023-52881",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "tcp: do not accept ACK of bytes we never sent",
"summary": "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(.",
"evidence": "osv:CVE-2023-52881",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "4.14.333",
"evidence": "/affected/1/ranges"
},
{
"value": "4.19.302",
"evidence": "/affected/1/ranges"
},
{
"value": "5.4.264",
"evidence": "/affected/1/ranges"
},
{
"value": "5.10.204",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.143",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.68",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.7",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "critical",
"structured": {
"id": "CVE-2023-52881",
"aliases": [
"CVE-2023-52881"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "354e4aa391ed50a4d827ff6fc11e0667d0859b25"
},
{
"fixed": "69eae75ca5255e876628ac5cee9eaab31f644b57"
},
{
"fixed": "458f07ffeccd17f99942311e09ef574ddf4a414a"
},
{
"fixed": "7ffff0cc929fdfc62a74b384c4903d6496c910f0"
},
{
"fixed": "b17a886ed29f3b70b78ccf632dad03e0c69e3c1a"
},
{
"fixed": "0d4e0afdd6658cd21dd5be61880411a2553fd1fc"
},
{
"fixed": "008b807fe487e0b15a3a6c39add4eb477f73e440"
},
{
"fixed": "2087d53a66e97a5eb5d1bf558d5bef9e5f891757"
},
{
"fixed": "3d501dd326fb1c73f1b8206d4c6e1d7b15c07e27"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "3.0.58"
},
{
"fixed": "3.1"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "3.2.37"
},
{
"fixed": "3.3"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "3.4.25"
},
{
"fixed": "3.5"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "8d15569e14cfcf9151e9e3b4c0cb98369943a2bb"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "e252bbd8c87b95e9cecdc01350fbb0b46a0f9bf1"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "2ee4432e82437a7c051c254b065fbf5d4581e1a3"
}
]
}
],
"versions": [
"v3.0.101",
"v3.0.100",
"v3.0.99",
"v3.0.98",
"v3.0.97",
"v3.0.96",
"v3.0.95",
"v3.0.94",
"v3.0.93",
"v3.0.92",
"v3.0.91",
"v3.0.90",
"v3.0.89",
"v3.0.88",
"v3.0.87",
"v3.0.86",
"v3.0.85",
"v3.0.84",
"v3.0.83",
"v3.0.82",
"v3.0.81",
"v3.0.80",
"v3.0.79",
"v3.0.78",
"v3.0.77",
"v3.0.76",
"v3.0.75",
"v3.0.74",
"v3.0.73",
"v3.0.72",
"v3.0.71",
"v3.0.70",
"v3.0.69",
"v3.0.68",
"v3.0.67",
"v3.0.66",
"v3.0.65",
"v3.0.64",
"v3.0.63",
"v3.0.62",
"v3.0.61",
"v3.0.60",
"v3.0.59",
"v3.0.58",
"v3.2.102",
"v3.2.101",
"v3.2.100",
"v3.2.99",
"v3.2.98",
"v3.2.97",
"v3.2.96",
"v3.2.95",
"v3.2.94",
"v3.2.93",
"v3.2.92",
"v3.2.91",
"v3.2.90",
"v3.2.89",
"v3.2.88",
"v3.2.87",
"v3.2.86",
"v3.2.85",
"v3.2.84",
"v3.2.83",
"v3.2.82",
"v3.2.81",
"v3.2.80",
"v3.2.79",
"v3.2.78",
"v3.2.77",
"v3.2.76",
"v3.2.75",
"v3.2.74",
"v3.2.73",
"v3.2.72",
"v3.2.71",
"v3.2.70",
"v3.2.69",
"v3.2.68",
"v3.2.67",
"v3.2.66",
"v3.2.65",
"v3.2.64",
"v3.2.63",
"v3.2.62",
"v3.2.61",
"v3.2.60",
"v3.2.59",
"v3.2.58",
"v3.2.57",
"v3.2.56",
"v3.2.55",
"v3.2.54",
"v3.2.53",
"v3.2.52",
"v3.2.51",
"v3.2.50",
"v3.2.49",
"v3.2.48",
"v3.2.47",
"v3.2.46",
"v3.2.45",
"v3.2.44",
"v3.2.43",
"v3.2.42",
"v3.2.41",
"v3.2.40",
"v3.2.39",
"v3.2.38",
"v3.2.37",
"v3.4.113",
"v3.4.112",
"v3.4.111",
"v3.4.110",
"v3.4.109",
"v3.4.108",
"v3.4.107",
"v3.4.106",
"v3.4.105",
"v3.4.104",
"v3.4.103",
"v3.4.102",
"v3.4.101",
"v3.4.100",
"v3.4.99",
"v3.4.98",
"v3.4.97",
"v3.4.96",
"v3.4.95",
"v3.4.94",
"v3.4.93",
"v3.4.92",
"v3.4.91",
"v3.4.90",
"v3.4.89",
"v3.4.88",
"v3.4.87",
"v3.4.86",
"v3.4.85",
"v3.4.84",
"v3.4.83",
"v3.4.82",
"v3.4.81",
"v3.4.80",
"v3.4.79",
"v3.4.78",
"v3.4.77",
"v3.4.76",
"v3.4.75",
"v3.4.74",
"v3.4.73",
"v3.4.72",
"v3.4.71",
"v3.4.70",
"v3.4.69",
"v3.4.68",
"v3.4.67",
"v3.4.66",
"v3.4.65",
"v3.4.64",
"v3.4.63",
"v3.4.62",
"v3.4.61",
"v3.4.60",
"v3.4.59",
"v3.4.58",
"v3.4.57",
"v3.4.56",
"v3.4.55",
"v3.4.54",
"v3.4.53",
"v3.4.52",
"v3.4.51",
"v3.4.50",
"v3.4.49",
"v3.4.48",
"v3.4.47",
"v3.4.46",
"v3.4.45",
"v3.4.44",
"v3.4.43",
"v3.4.42",
"v3.4.41",
"v3.4.40",
"v3.4.39",
"v3.4.38",
"v3.4.37",
"v3.4.36",
"v3.4.35",
"v3.4.34",
"v3.4.33",
"v3.4.32",
"v3.4.31",
"v3.4.30",
"v3.4.29",
"v3.4.28",
"v3.4.27",
"v3.4.26",
"v3.4.25"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2023-52881.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "3.8.0"
},
{
"fixed": "4.14.333"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "4.15.0"
},
{
"fixed": "4.19.302"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "4.20.0"
},
{
"fixed": "5.4.264"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.5.0"
},
{
"fixed": "5.10.204"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.143"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.68"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.7"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2023-52881.json"
}
}
],
"modified": "2026-10-28T02:30:34.300285430Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/008b807fe487e0b15a3a6c39add4eb477f73e440",
"https://git.kernel.org/stable/c/0d4e0afdd6658cd21dd5be61880411a2553fd1fc",
"https://git.kernel.org/stable/c/2087d53a66e97a5eb5d1bf558d5bef9e5f891757",
"https://git.kernel.org/stable/c/3d501dd326fb1c73f1b8206d4c6e1d7b15c07e27",
"https://git.kernel.org/stable/c/458f07ffeccd17f99942311e09ef574ddf4a414a",
"https://git.kernel.org/stable/c/69eae75ca5255e876628ac5cee9eaab31f644b57",
"https://git.kernel.org/stable/c/7ffff0cc929fdfc62a74b384c4903d6496c910f0",
"https://git.kernel.org/stable/c/b17a886ed29f3b70b78ccf632dad03e0c69e3c1a",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/52xxx/CVE-2023-52881.json",
"https://nvd.nist.gov/vuln/detail/CVE-2023-52881",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/52xxx/CVE-2023-52881.json"
}
},
"related_cves": [
{
"value": "CVE-2023-52881",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 501217,
"published_at": "2024-05-29T10:15:14.186+00:00"
}