CVE-2025-21710

{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2025-21710", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-12-29T08:45:45.752Z", "datePublished": "2025-02-27T02:07:23.112Z", "dateUpdated": "2026-08-05T11:53:49.495Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-08-05T11:53:49.495Z"}, "descriptions": [{"lang": "en", "value": "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(->)\n// tcp_rcv_established(->)\n[5201<->39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====\n[5201<->39222]: tcp_data_queue(->)\n[5201<->39222]: 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->260034360 (124968), unread 5565800, qlen 85, ofoq 0]\n [OFO queue: gap: 65480, len: 0]\n[5201<->39222]: tcp_data_queue(<-)\n[5201<->39222]: __tcp_transmit_skb(->)\n [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\n[5201<->39222]: tcp_select_window(->)\n[5201<->39222]: (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE\n [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\n returning 0\n[5201<->39222]: tcp_select_window(<-)\n[5201<->39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160\n[5201<->39222]: [__tcp_transmit_skb(<-)\n[5201<->39222]: tcp_rcv_established(<-)\n[5201<->39222]: tcp_v4_rcv(<-)\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->rcv_wnd and tp->rcv_wup accordingly, which means\n// we unconditionally shrink the window.\n\n[5201<->39222]: tcp_recvmsg_locked(->)\n[5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160\n[5201<->39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368]\n[5201<->39222]: [new_win >= (2 * win_now) ? --> time_to_ack = 0]\n[5201<->39222]: NOT calling tcp_send_ack()\n [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\n[5201<->39222]: __tcp_cleanup_rbuf(<-)\n [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n [copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0]\n returning 6104 bytes\n[5201<->39222]: tcp_recvmsg_locked(<-)\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->rcv_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<->39222]: tcp_recvmsg_locked(->)\n[5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160\n[5201<->39222]: [new_win = 262144, win_now = 131184, 2 * win_n\n---truncated---"}], "metrics": [{"cvssV3_1": {"version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H", "baseScore": 8.2, "baseSeverity": "HIGH"}, "scenarios": [{"lang": "en", "value": "AV:N - The bug is in the core TCP receive/output path (`tcp_select_window` via `tcp_data_queue`) and is triggered purely by the traffic pattern of a remote peer driving the receive socket into memory squeeze. Any routable TCP service \u2014 HTTP, SSH, ksmbd, nfsd, database \u2014 is reachable over the network.\nAC:L - The attacker controls both preconditions: skb truesize amplification lets a flood of small segments exhaust `sk_rmem_alloc`/`tcp_mem` while consuming little sequence space, which reliably leaves `tcp_receive_window()` above half the maximum at squeeze time \u2014 exactly the state that makes the `new_window >= 2 * rcv_window_now` test in `__tcp_cleanup_rbuf()` permanently unsatisfiable \u2014 and the attacker then simply declines to send zero-window probes, which is the only recovery path.\nPR:N - No authentication or privilege is needed; the condition is reached in `tcp_data_queue()` on established connections before any application-layer authentication, so any unauthenticated client of any TCP listener can drive it.\nUI:N - Triggering requires only that the target socket receive attacker-supplied data; no action by a local user or administrator is involved.\nS:U - The inconsistent window state and the resulting stall are confined to the kernel TCP stack and the sockets it owns, with no crossing of a security authority boundary.\nC:N - No uninitialized, out-of-bounds, or freed memory is read or transmitted; the defect is limited to bookkeeping of `tp->rcv_wnd`/`tp->rcv_wup` and produces no disclosure of kernel or other sockets' data.\nI:L - The attacker causes the connection's protocol state to be left incorrect \u2014 the stored receive window diverges from what was advertised, and the fix explicitly notes the pre-fix path transmits regressing `th->ack_seq` values that are \"wrong from a protocol viewpoint\" \u2014 pinning the peer's `snd_wnd` at a bogus zero; the modification is bounded and its consequences are not attacker-directed.\nA:H - The connection enters a permanent deadlock \u2014 the receive queue empties but no window update is ever sent and the peer never transmits again \u2014 indefinitely pinning a socket and, for blocking servers, a worker thread; repeated across many connections this exhausts a server's connection and thread pools, and TCP keepalive is disabled by default so nothing breaks the stall."}]}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["net/ipv4/tcp_output.c"], "versions": [{"version": "e2142825c120d4317abf7160a0fc34b3de532586", "lessThan": "b01e7ceb35dcb7ffad413da657b78c3340a09039", "status": "affected", "versionType": "git"}, {"version": "e2142825c120d4317abf7160a0fc34b3de532586", "lessThan": "1dd823a46e25ffde1492c391934f69a9e5eb574f", "status": "affected", "versionType": "git"}, {"version": "e2142825c120d4317abf7160a0fc34b3de532586", "lessThan": "b4055e2fe96f4ef101d8af0feb056d78d77514ff", "status": "affected", "versionType": "git"}, {"version": "e2142825c120d4317abf7160a0fc34b3de532586", "lessThan": "8c670bdfa58e48abad1d5b6ca1ee843ca91f7303", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["net/ipv4/tcp_output.c"], "versions": [{"version": "6.6", "status": "affected"}, {"version": "0", "lessThan": "6.6", "status": "unaffected", "versionType": "semver"}, {"version": "6.6.76", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.12.13", "lessThanOrEqual": "6.12.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.13.2", "lessThanOrEqual": "6.13.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.14", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "cpeApplicability": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.6", "versionEndExcluding": "6.6.76"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.6", "versionEndExcluding": "6.12.13"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.6", "versionEndExcluding": "6.13.2"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.6", "versionEndExcluding": "6.14"}]}]}], "references": [{"url": "https://git.kernel.org/stable/c/b01e7ceb35dcb7ffad413da657b78c3340a09039"}, {"url": "https://git.kernel.org/stable/c/1dd823a46e25ffde1492c391934f69a9e5eb574f"}, {"url": "https://git.kernel.org/stable/c/b4055e2fe96f4ef101d8af0feb056d78d77514ff"}, {"url": "https://git.kernel.org/stable/c/8c670bdfa58e48abad1d5b6ca1ee843ca91f7303"}], "title": "tcp: correct handling of extreme memory squeeze", "x_generator": {"engine": "bippy-1.2.0"}}}}

{}

{"affected": [{"affectedData": [{"defaultStatus": "unaffected", "product": "Linux", "programFiles": ["net/ipv4/tcp_output.c"], "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "versions": [{"lessThan": "b01e7ceb35dcb7ffad413da657b78c3340a09039", "status": "affected", "version": "e2142825c120d4317abf7160a0fc34b3de532586", "versionType": "git"}, {"lessThan": "1dd823a46e25ffde1492c391934f69a9e5eb574f", "status": "affected", "version": "e2142825c120d4317abf7160a0fc34b3de532586", "versionType": "git"}, {"lessThan": "b4055e2fe96f4ef101d8af0feb056d78d77514ff", "status": "affected", "version": "e2142825c120d4317abf7160a0fc34b3de532586", "versionType": "git"}, {"lessThan": "8c670bdfa58e48abad1d5b6ca1ee843ca91f7303", "status": "affected", "version": "e2142825c120d4317abf7160a0fc34b3de532586", "versionType": "git"}]}, {"defaultStatus": "affected", "product": "Linux", "programFiles": ["net/ipv4/tcp_output.c"], "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "versions": [{"status": "affected", "version": "6.6"}, {"lessThan": "6.6", "status": "unaffected", "version": "0", "versionType": "semver"}, {"lessThanOrEqual": "6.6.*", "status": "unaffected", "version": "6.6.76", "versionType": "semver"}, {"lessThanOrEqual": "6.12.*", "status": "unaffected", "version": "6.12.13", "versionType": "semver"}, {"lessThanOrEqual": "6.13.*", "status": "unaffected", "version": "6.13.2", "versionType": "semver"}, {"lessThanOrEqual": "*", "status": "unaffected", "version": "6.14", "versionType": "original_commit_for_fix"}]}], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "C9762EFE-508E-462C-B4F6-A1D1871149B5", "versionEndExcluding": "6.6.76", "versionStartIncluding": "6.6", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "2897389C-A8C3-4D69-90F2-E701B3D66373", "versionEndExcluding": "6.12.13", "versionStartIncluding": "6.7", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "6D4116B1-1BFD-4F23-BA84-169CC05FC5A3", "versionEndExcluding": "6.13.2", "versionStartIncluding": "6.13", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "descriptions": [{"lang": "en", "value": "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(->)\n// tcp_rcv_established(->)\n[5201<->39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====\n[5201<->39222]: tcp_data_queue(->)\n[5201<->39222]: 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->260034360 (124968), unread 5565800, qlen 85, ofoq 0]\n [OFO queue: gap: 65480, len: 0]\n[5201<->39222]: tcp_data_queue(<-)\n[5201<->39222]: __tcp_transmit_skb(->)\n [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\n[5201<->39222]: tcp_select_window(->)\n[5201<->39222]: (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE\n [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\n returning 0\n[5201<->39222]: tcp_select_window(<-)\n[5201<->39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160\n[5201<->39222]: [__tcp_transmit_skb(<-)\n[5201<->39222]: tcp_rcv_established(<-)\n[5201<->39222]: tcp_v4_rcv(<-)\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->rcv_wnd and tp->rcv_wup accordingly, which means\n// we unconditionally shrink the window.\n\n[5201<->39222]: tcp_recvmsg_locked(->)\n[5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160\n[5201<->39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368]\n[5201<->39222]: [new_win >= (2 * win_now) ? --> time_to_ack = 0]\n[5201<->39222]: NOT calling tcp_send_ack()\n [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\n[5201<->39222]: __tcp_cleanup_rbuf(<-)\n [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n [copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0]\n returning 6104 bytes\n[5201<->39222]: tcp_recvmsg_locked(<-)\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->rcv_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<->39222]: tcp_recvmsg_locked(->)\n[5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160\n[5201<->39222]: [new_win = 262144, win_now = 131184, 2 * win_n\n---truncated---"}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: gesti\u00f3n correcta de la compresi\u00f3n extrema de memoria Las pruebas con iperf3 utilizando el empalmador de protocolo \"pasta\" han revelado un problema en la forma en que tcp gestiona la publicidad de ventanas en situaciones de compresi\u00f3n extrema de memoria. Bajo presi\u00f3n de memoria, un endpoint de socket puede anunciar temporalmente una ventana de tama\u00f1o cero, pero esto no se almacena como parte de los datos del socket. El razonamiento detr\u00e1s de esto es que se considera una configuraci\u00f3n temporal que no deber\u00eda influir en ning\u00fan c\u00e1lculo posterior. Sin embargo, si nos quedamos en un valor desafortunado del tama\u00f1o de ventana actual, el algoritmo que selecciona un nuevo valor fallar\u00e1 constantemente en anunciar una ventana distinta de cero una vez que hayamos liberado suficiente memoria. Esto significa que la noci\u00f3n de este lado del tama\u00f1o de ventana actual es diferente de la \u00faltima anunciada al par, lo que hace que este \u00faltimo no env\u00ede ning\u00fan dato para resolver la situaci\u00f3n. El problema ocurre en el lado del servidor iperf3, y el socket en cuesti\u00f3n es un socket completamente normal con la configuraci\u00f3n predeterminada para el kernel fedora40. No utilizamos SO_PEEK o SO_RCVBUF en el socket. El siguiente extracto de una sesi\u00f3n de registro, con comentarios propios agregados, muestra con m\u00e1s detalle lo que est\u00e1 sucediendo: // tcp_v4_rcv(-&gt;) // tcp_rcv_established(-&gt;) [5201&lt;-&gt;39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ==== [5201&lt;-&gt;39222]: tcp_data_queue(-&gt;) [5201&lt;-&gt;39222]: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 259909392-&gt;260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0] [5201&lt;-&gt;39222]: tcp_data_queue(&lt;-) [5201&lt;-&gt;39222]: __tcp_transmit_skb(-&gt;) [tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160] [5201&lt;-&gt;39222]: tcp_select_window(-&gt;) [5201&lt;-&gt;39222]: (inet_csk(sk)-&gt;icsk_ack.pending &amp; ICSK_ACK_NOMEM) ? --&gt; TRUE [tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160] returning 0 [5201&lt;-&gt;39222]: tcp_select_window(&lt;-) [5201&lt;-&gt;39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160 [5201&lt;-&gt;39222]: [__tcp_transmit_skb(&lt;-) [5201&lt;-&gt;39222]: tcp_rcv_established(&lt;-) [5201&lt;-&gt;39222]: tcp_v4_rcv(&lt;-) // La cola de recepci\u00f3n est\u00e1 en 85 b\u00faferes y nos hemos quedado sin memoria. // Descartamos el b\u00fafer entrante, aunque est\u00e9 en secuencia, y decidimos // enviar un anuncio con una ventana de cero. // No actualizamos tp-&gt;rcv_wnd y tp-&gt;rcv_wup en consecuencia, lo que significa // que reducimos incondicionalmente la ventana. [5201&lt;-&gt;39222]: tcp_recvmsg_locked(-&gt;) [5201&lt;-&gt;39222]: __tcp_cleanup_rbuf(-&gt;) tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160 [5201&lt;-&gt;39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368] [5201&lt;-&gt;39222]: [new_win &gt;= (2 * win_now) ? --&gt; time_to_ack = 0] [5201&lt;-&gt;39222]: NOT calling tcp_send_ack() [tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160] [5201&lt;-&gt;39222]: __tcp_cleanup_rbuf(&lt;-) [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 260040464-&gt;260040464 (0), unread 5559696, qlen 85, ofoq 0] returning 6104 bytes [5201&lt;-&gt;39222]: tcp_recvmsg_locked(&lt;-) // Despu\u00e9s de cada lectura, el algoritmo para calcular la nueva ventana de recepci\u00f3n // en __tcp_cleanup_rbuf() encuentra que es demasiado peque\u00f1a para anunciar // o actualizar tp-&gt;rcv_wnd. // Mientras tanto, el par piensa que la ventana es cero y no enviar\u00e1 // m\u00e1s datos para activar una actualizaci\u00f3n desde el lado del modo de interrupci\u00f3n. [5201&lt;-&gt;39222]: tcp_recvmsg_locked(-&gt;) [5201&lt;-&gt;39222]: __tcp_cleanup_rbuf(-&gt;) tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160 [5201&lt;-&gt;39222]: [new"}], "id": "CVE-2025-21710", "lastModified": "2026-07-30T06:20:26.450", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "baseScore": 8.2, "baseSeverity": "HIGH", "confidentialityImpact": "NONE", "integrityImpact": "LOW", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H", "version": "3.1"}, "exploitabilityScore": 3.9, "impactScore": 4.2, "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "type": "Secondary"}, {"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary"}]}, "published": "2025-02-27T02:15:14.657", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/1dd823a46e25ffde1492c391934f69a9e5eb574f"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/8c670bdfa58e48abad1d5b6ca1ee843ca91f7303"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/b01e7ceb35dcb7ffad413da657b78c3340a09039"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/b4055e2fe96f4ef101d8af0feb056d78d77514ff"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Modified", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-667"}], "source": "nvd@nist.gov", "type": "Primary"}]}

{"bugzilla": {"description": "kernel: tcp: correct handling of extreme memory squeeze", "id": "2348607", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2348607"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.5", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "details": ["In the Linux kernel, the following vulnerability has been resolved:\ntcp: correct handling of extreme memory squeeze\nTesting with iperf3 using the \"pasta\" protocol splicer has revealed\na problem in the way tcp handles window advertising in extreme memory\nsqueeze situations.\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.\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.\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.\nThe following excerpt of a logging session, with own comments added,\nshows more in detail what is happening:\n// tcp_v4_rcv(->)\n// tcp_rcv_established(->)\n[5201<->39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====\n[5201<->39222]: tcp_data_queue(->)\n[5201<->39222]: 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->260034360 (124968), unread 5565800, qlen 85, ofoq 0]\n[OFO queue: gap: 65480, len: 0]\n[5201<->39222]: tcp_data_queue(<-)\n[5201<->39222]: __tcp_transmit_skb(->)\n[tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\n[5201<->39222]: tcp_select_window(->)\n[5201<->39222]: (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE\n[tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\nreturning 0\n[5201<->39222]: tcp_select_window(<-)\n[5201<->39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160\n[5201<->39222]: [__tcp_transmit_skb(<-)\n[5201<->39222]: tcp_rcv_established(<-)\n[5201<->39222]: tcp_v4_rcv(<-)\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->rcv_wnd and tp->rcv_wup accordingly, which means\n// we unconditionally shrink the window.\n[5201<->39222]: tcp_recvmsg_locked(->)\n[5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160\n[5201<->39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368]\n[5201<->39222]: [new_win >= (2 * win_now) ? --> time_to_ack = 0]\n[5201<->39222]: NOT calling tcp_send_ack()\n[tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\n[5201<->39222]: __tcp_cleanup_rbuf(<-)\n[rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n[copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0]\nreturning 6104 bytes\n[5201<->39222]: tcp_recvmsg_locked(<-)\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->rcv_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[5201<->39222]: tcp_recvmsg_locked(->)\n[5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160\n[5201<->39222]: [new_win = 262144, win_now = 131184, 2 * win_n\n---truncated---"], "name": "CVE-2025-21710", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:10", "fix_state": "Will not fix", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 10"}, {"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2025-02-27T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2025-21710\nhttps://nvd.nist.gov/vuln/detail/CVE-2025-21710\nhttps://lore.kernel.org/linux-cve-announce/2025022644-CVE-2025-21710-5e28@gregkh/T"], "threat_severity": "Moderate"}

{}