{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2023-52881 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2023-52881 is a critical vulnerability in Linux kernel, published on 29 May 2024. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2023-52881 and fix it if it is affected.\n\nWhat it is: CVE-2023-52881 is a critical vulnerability in Linux kernel, published on 29 May 2024. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2023-52881 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2023-52881/ (Markdown: https://insights.sbomify.com/CVE-2023-52881/index.md)","id":"CVE-2023-52881","markdown":"https://insights.sbomify.com/CVE-2023-52881/index.md","name":"CVE-2023-52881","record":{"aliases":["BELL-CVE-2023-52881","DEBIAN-CVE-2023-52881","UBUNTU-CVE-2023-52881"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["security_bypass"],"network_reachable":"yes","non_default_config":false,"product_category":"Linux kernel TCP","requires_auth":"none","summary":"The Linux kernel TCP stack improperly validates ACK numbers, allowing attackers to bypass security checks by acknowledging bytes never sent.","user_interaction":"not_required","vuln_class":"other"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":9.8,"severity":"critical","source":"cna","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: do not accept ACK of bytes we never sent\n\nThis patch is based on a detailed report and ideas from Yepeng Pan\nand Christian Rossow.\n\nACK seq validation is currently following RFC 5961 5.2 guidelines:\n\n   The ACK value is considered acceptable only if\n   it is in the range of ((SND.UNA - MAX.SND.WND) \u003c= SEG.ACK \u003c=\n   SND.NXT).  All incoming segments whose ACK value doesn't satisfy the\n   above condition MUST be discarded and an ACK sent back.  It needs to\n   be noted that RFC 793 on page 72 (fifth check) says: \"If the ACK is a\n   duplicate (SEG.ACK \u003c SND.UNA), it can be ignored.  If the ACK\n   acknowledges something not yet sent (SEG.ACK \u003e SND.NXT) then send an\n   ACK, drop the segment, and return\".  The \"ignored\" above implies that\n   the processing of the incoming data segment continues, which means\n   the ACK value is treated as acceptable.  This mitigation makes the\n   ACK check more stringent since any ACK \u003c SND.UNA wouldn't be\n   accepted, instead only ACKs that are in the range ((SND.UNA -\n   MAX.SND.WND) \u003c= SEG.ACK \u003c= SND.NXT) get through.\n\nThis can be refined for new (and possibly spoofed) flows,\nby not accepting ACK for bytes that were never sent.\n\nThis greatly improves TCP security at a little cost.\n\nI added a Fixes: tag to make sure this patch will reach stable trees,\neven if the 'blamed' patch was adhering to the RFC.\n\ntp-\u003ebytes_acked was added in linux-4.2\n\nFollowing packetdrill test (courtesy of Yepeng Pan) shows\nthe issue at hand:\n\n0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3\n+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0\n+0 bind(3, ..., ...) = 0\n+0 listen(3, 1024) = 0\n\n// ---------------- Handshake ------------------- //\n\n// when window scale is set to 14 the window size can be extended to\n// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet\n// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)\n// ,though this ack number acknowledges some data never\n// sent by the server.\n\n+0 \u003c S 0:0(0) win 65535 \u003cmss 1400,nop,wscale 14\u003e\n+0 \u003e S. 0:0(0) ack 1 \u003c...\u003e\n+0 \u003c . 1:1(0) ack 1 win 65535\n+0 accept(3, ..., ...) = 4\n\n// For the established connection, we send an ACK packet,\n// the ack packet uses ack number 1 - 1073725300 + 2^32,\n// where 2^32 is used to wrap around.\n// Note: we used 1073725300 instead of 1073725440 to avoid possible\n// edge cases.\n// 1 - 1073725300 + 2^32 = 3221241997\n\n// Oops, old kernels happily accept this packet.\n+0 \u003c . 1:1001(1000) ack 3221241997 win 65535\n\n// After the kernel fix the following will be replaced by a challenge ACK,\n// and prior malicious frame would be dropped.\n+0 \u003e . 1:1(0) ack 1001","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"tcp: do not accept ACK of bytes we never sent","id":"CVE-2023-52881","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"other","year":"2023"},"n_packages":0,"n_references":8,"next":{"headline":"clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change","id":"CVE-2023-52882"},"packages":[],"prev":{"headline":"tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc","id":"CVE-2023-52880"},"products":["Linux"],"published":"2024-05-29","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-08-05","vendors":["Linux"]},"summary":"The Linux kernel TCP stack improperly validates ACK numbers, allowing attackers to bypass security checks by acknowledging bytes never sent.","url":"https://insights.sbomify.com/CVE-2023-52881/"}