{ "schema_version": "1.6.1", "id": "RPI-CVE-2025-37894", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2025-37894" ], "published": "2025-05-20T15:22:31Z", "summary": "net: use sock_gen_put() when sk_state is TCP_TIME_WAIT", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: use sock_gen_put() when sk_state is TCP_TIME_WAIT\n\nIt is possible for a pointer of type struct inet_timewait_sock to be\nreturned from the functions __inet_lookup_established() and\n__inet6_lookup_established(). This can cause a crash when the\nreturned pointer is of type struct inet_timewait_sock and\nsock_put() is called on it. The following is a crash call stack that\nshows sk->sk_wmem_alloc being accessed in sk_free() during the call to\nsock_put() on a struct inet_timewait_sock pointer. To avoid this issue,\nuse sock_gen_put() instead of sock_put() when sk->sk_state\nis TCP_TIME_WAIT.\n\nmrdump.ko ipanic() + 120\nvmlinux notifier_call_chain(nr_to_call=-1, nr_calls=0) + 132\nvmlinux atomic_notifier_call_chain(val=0) + 56\nvmlinux panic() + 344\nvmlinux add_taint() + 164\nvmlinux end_report() + 136\nvmlinux kasan_report(size=0) + 236\nvmlinux report_tag_fault() + 16\nvmlinux do_tag_recovery() + 16\nvmlinux __do_kernel_fault() + 88\nvmlinux do_bad_area() + 28\nvmlinux do_tag_check_fault() + 60\nvmlinux do_mem_abort() + 80\nvmlinux el1_abort() + 56\nvmlinux el1h_64_sync_handler() + 124\nvmlinux > 0xFFFFFFC080011294()\nvmlinux __lse_atomic_fetch_add_release(v=0xF2FFFF82A896087C)\nvmlinux __lse_atomic_fetch_sub_release(v=0xF2FFFF82A896087C)\nvmlinux arch_atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C)\n+ 8\nvmlinux raw_atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C)\n+ 8\nvmlinux atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C) + 8\nvmlinux __refcount_sub_and_test(i=1, r=0xF2FFFF82A896087C,\noldp=0) + 8\nvmlinux __refcount_dec_and_test(r=0xF2FFFF82A896087C, oldp=0) + 8\nvmlinux refcount_dec_and_test(r=0xF2FFFF82A896087C) + 8\nvmlinux sk_free(sk=0xF2FFFF82A8960700) + 28\nvmlinux sock_put() + 48\nvmlinux tcp6_check_fraglist_gro() + 236\nvmlinux tcp6_gro_receive() + 624\nvmlinux ipv6_gro_receive() + 912\nvmlinux dev_gro_receive() + 1116\nvmlinux napi_gro_receive() + 196\nccmni.ko ccmni_rx_callback() + 208\nccmni.ko ccmni_queue_recv_skb() + 388\nccci_dpmaif.ko dpmaif_rxq_push_thread() + 1088\nvmlinux kthread() + 268\nvmlinux 0xFFFFFFC08001F30C()", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.12.20-1+rpt1~bpo12+1", "1:6.12.25-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.12.20+rpt-rpi-2712", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v6", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v7", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v7l", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v8", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-2712", "binary_version": "1:6.12.25-1+rpt1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v6", "binary_version": "1:6.12.25-1+rpt1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v7", "binary_version": "1:6.12.25-1+rpt1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v7l", "binary_version": "1:6.12.25-1+rpt1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v8", "binary_version": "1:6.12.25-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.12.20-1+rpt1~bpo12+1": { "linux_commit": "cd231d4775b14f228606c09f219b48308f6ab3aa", "upstream_version": "6.12.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.28" }, "1:6.12.25-1+rpt1": { "linux_commit": "3dd2c2c507c271d411fab2e82a2b3b7e0b6d3f16", "upstream_version": "6.12.25", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.28" } } } }, { "package": { "ecosystem": "Raspberry Pi OS:13", "name": "linux" }, "versions": [ "1:6.12.19-1+rpt1~bpo12+1", "1:6.12.19-1+rpt1", "1:6.12.20-1+rpt1", "1:6.12.25-1+rpt1+trixie" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.12.19+rpt-rpi-2712", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v6", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v7", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v7l", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v8", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-2712", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v6", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v7", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v7l", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v8", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-2712", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v6", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v7", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v7l", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v8", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-2712", "binary_version": "1:6.12.25-1+rpt1+trixie" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v6", "binary_version": "1:6.12.25-1+rpt1+trixie" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v7", "binary_version": "1:6.12.25-1+rpt1+trixie" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v8", "binary_version": "1:6.12.25-1+rpt1+trixie" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v8-rt", "binary_version": "1:6.12.25-1+rpt1+trixie" } ] }, "database_specific": { "per_version": { "1:6.12.19-1+rpt1~bpo12+1": { "linux_commit": "121c2c384b9c2f4790ffb31b2cd25c7d75c8fda0", "upstream_version": "6.12.19", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.28" }, "1:6.12.19-1+rpt1": { "linux_commit": "121c2c384b9c2f4790ffb31b2cd25c7d75c8fda0", "upstream_version": "6.12.19", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.28" }, "1:6.12.20-1+rpt1": { "linux_commit": "cd231d4775b14f228606c09f219b48308f6ab3aa", "upstream_version": "6.12.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.28" }, "1:6.12.25-1+rpt1+trixie": { "linux_commit": "3dd2c2c507c271d411fab2e82a2b3b7e0b6d3f16", "upstream_version": "6.12.25", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.28" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2025-37894" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c0dba059b118b5206e755042b15b49368a388898" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/786650e644c5b1c063921799ca203c0b8670d79a" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f920436a44295ca791ebb6dae3f4190142eec703" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T12:19:11Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 9.8, "cvss_v3_severity": "Critical", "scenario": "AV:N - The vulnerable code executes in the GRO packet-receive softirq path (`napi_gro_receive` \u2192 `ipv4/ipv6_gro_receive` \u2192 `tcp4/6_gro_receive` \u2192 `tcp4/6_check_fraglist_gro`), triggered purely by TCP segments arriving from the network. The reported real-world crash occurred on a modem/WAN interface receiving internet traffic.\nAC:L - The attacker controls both sides of the race \u2014 it creates the TIME_WAIT sockets by opening and closing connections, deterministically tears them down on demand by sending an RST or out-of-window SYN for the same 4-tuple (`TCP_TW_RST`/`TCP_TW_SYN` \u2192 `inet_twsk_deschedule_put()`), and concurrently floods matching segments that drive the GRO lookup on other RX queues, so the final `sock_put()` reliably lands on a dying twsk. It can also groom the dedicated `tw_sock_TCP` slab to place a chosen victim object next to the out-of-bounds decrement.\nPR:N - No credentials or privileges of any kind are needed \u2014 GRO processing happens in softirq on raw received packets long before any socket-level authentication or delivery, and creating TIME_WAIT state only requires connecting to any reachable TCP port or emitting traffic through the box.\nUI:N - Exploitation is fully driven by attacker-transmitted packets; no local user action, mount, or file access is required.\nS:U - The out-of-bounds decrement, the potential indirect call, and the resulting corruption are all confined to the kernel's own memory and security authority, with no crossing into a hypervisor, IOMMU, or other security scope.\nC:H - The mistyped free reads far past the 264-byte timewait object \u2014 `sk_prot_creator` at +600 and `sk_destruct` at +736 \u2014 and the corrupted neighbouring `hlist_nulls` pointers turn subsequent ehash walks into reads of attacker-influenced addresses, giving a path to arbitrary kernel memory disclosure.\nI:H - `sk_free()` performs an atomic 32-bit read-modify-write 116 bytes out of bounds into an adjacent live `tcp_timewait_sock`, corrupting its hash-list pointers, which are later written through by `sk_nulls_del_node_init_rcu()`; if the OOB word reads 1, `__sk_destruct()` additionally makes an indirect call through a function pointer sourced from out-of-bounds heap data, yielding a control-flow hijack primitive.\nA:H - The bug was reported as a confirmed kernel panic (KASAN/MTE tag-check fault in `sk_free()` \u2192 `panic()`), and a remote unauthenticated attacker can retrigger the out-of-bounds refcount decrement repeatedly, crashing the machine at will." } } }