{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2025-21710 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2025-21710 is a high-severity denial of service vulnerability in Linux kernel, published on 27 Feb 2025. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2025-21710 and fix it if it is affected.\n\nWhat it is: CVE-2025-21710 is a high-severity denial of service vulnerability in Linux kernel, published on 27 Feb 2025. 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-2025-21710 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-2025-21710/ (Markdown: https://insights.sbomify.com/CVE-2025-21710/index.md)","id":"CVE-2025-21710","markdown":"https://insights.sbomify.com/CVE-2025-21710/index.md","name":"CVE-2025-21710","record":{"aliases":["BELL-CVE-2025-21710","DEBIAN-CVE-2025-21710","GHSA-q383-xwj3-rcf5","ROOT-OS-UBUNTU-2404-CVE-2025-21710","UBUNTU-CVE-2025-21710"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"yes","non_default_config":false,"product_category":"Linux kernel TCP","requires_auth":"none","summary":"A flaw in Linux kernel TCP window handling under memory pressure can cause connections to stall, leading to denial of service.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":8.2,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H","version":"3.1"},"cwes":[{"id":"CWE-667","name":"Improper Locking"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: correct handling of extreme memory squeeze\n\nTesting with iperf3 using the \"pasta\" protocol splicer has revealed\na problem in the way tcp handles window advertising in extreme memory\nsqueeze situations.\n\nUnder memory pressure, a socket endpoint may temporarily advertise\na zero-sized window, but this is not stored as part of the socket data.\nThe reasoning behind this is that it is considered a temporary setting\nwhich shouldn't influence any further calculations.\n\nHowever, if we happen to stall at an unfortunate value of the current\nwindow size, the algorithm selecting a new value will consistently fail\nto advertise a non-zero window once we have freed up enough memory.\nThis means that this side's notion of the current window size is\ndifferent from the one last advertised to the peer, causing the latter\nto not send any data to resolve the sitution.\n\nThe problem occurs on the iperf3 server side, and the socket in question\nis a completely regular socket with the default settings for the\nfedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.\n\nThe following excerpt of a logging session, with own comments added,\nshows more in detail what is happening:\n\n//              tcp_v4_rcv(-\u003e)\n//                tcp_rcv_established(-\u003e)\n[5201\u003c-\u003e39222]:     ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====\n[5201\u003c-\u003e39222]:     tcp_data_queue(-\u003e)\n[5201\u003c-\u003e39222]:        DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM\n                       [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n                       [copied_seq 259909392-\u003e260034360 (124968), unread 5565800, qlen 85, ofoq 0]\n                       [OFO queue: gap: 65480, len: 0]\n[5201\u003c-\u003e39222]:     tcp_data_queue(\u003c-)\n[5201\u003c-\u003e39222]:     __tcp_transmit_skb(-\u003e)\n                        [tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160]\n[5201\u003c-\u003e39222]:       tcp_select_window(-\u003e)\n[5201\u003c-\u003e39222]:         (inet_csk(sk)-\u003eicsk_ack.pending \u0026 ICSK_ACK_NOMEM) ? --\u003e TRUE\n                        [tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160]\n                        returning 0\n[5201\u003c-\u003e39222]:       tcp_select_window(\u003c-)\n[5201\u003c-\u003e39222]:       ADVERTISING WIN 0, ACK_SEQ: 265600160\n[5201\u003c-\u003e39222]:     [__tcp_transmit_skb(\u003c-)\n[5201\u003c-\u003e39222]:   tcp_rcv_established(\u003c-)\n[5201\u003c-\u003e39222]: tcp_v4_rcv(\u003c-)\n\n// Receive queue is at 85 buffers and we are out of memory.\n// We drop the incoming buffer, although it is in sequence, and decide\n// to send an advertisement with a window of zero.\n// We don't update tp-\u003ercv_wnd and tp-\u003ercv_wup accordingly, which means\n// we unconditionally shrink the window.\n\n[5201\u003c-\u003e39222]: tcp_recvmsg_locked(-\u003e)\n[5201\u003c-\u003e39222]:   __tcp_cleanup_rbuf(-\u003e) tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160\n[5201\u003c-\u003e39222]:     [new_win = 0, win_now = 131184, 2 * win_now = 262368]\n[5201\u003c-\u003e39222]:     [new_win \u003e= (2 * win_now) ? --\u003e time_to_ack = 0]\n[5201\u003c-\u003e39222]:     NOT calling tcp_send_ack()\n                    [tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160]\n[5201\u003c-\u003e39222]:   __tcp_cleanup_rbuf(\u003c-)\n                  [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n                  [copied_seq 260040464-\u003e260040464 (0), unread 5559696, qlen 85, ofoq 0]\n                  returning 6104 bytes\n[5201\u003c-\u003e39222]: tcp_recvmsg_locked(\u003c-)\n\n// After each read, the algorithm for calculating the new receive\n// window in __tcp_cleanup_rbuf() finds it is too small to advertise\n// or to update tp-\u003ercv_wnd.\n// Meanwhile, the peer thinks the window is zero, and will not send\n// any more data to trigger an update from the interrupt mode side.\n\n[5201\u003c-\u003e39222]: tcp_recvmsg_locked(-\u003e)\n[5201\u003c-\u003e39222]:   __tcp_cleanup_rbuf(-\u003e) tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160\n[5201\u003c-\u003e39222]:     [new_win = 262144, win_now = 131184, 2 * win_n\n---truncated---","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: correct handling of extreme memory squeeze","id":"CVE-2025-21710","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"denial_of_service","year":"2025"},"n_packages":0,"n_references":4,"next":{"headline":"net/rose: prevent integer overflows in rose_setsockopt()","id":"CVE-2025-21711"},"packages":[],"prev":{"headline":"kernel: be more careful about dup_mmap() failures and uprobe registering","id":"CVE-2025-21709"},"products":["Linux"],"published":"2025-02-27","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":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-08-05","vendors":["Linux"]},"summary":"A flaw in Linux kernel TCP window handling under memory pressure can cause connections to stall, leading to denial of service.","url":"https://insights.sbomify.com/CVE-2025-21710/"}