{ "schema_version": "1.6.1", "id": "RPI-CVE-2025-37756", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2025-37756" ], "published": "2025-05-01T13:03:03Z", "summary": "net: tls: explicitly disallow disconnect", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: explicitly disallow disconnect\n\nsyzbot discovered that it can disconnect a TLS socket and then\nrun into all sort of unexpected corner cases. I have a vague\nrecollection of Eric pointing this out to us a long time ago.\nSupporting disconnect is really hard, for one thing if offload\nis enabled we'd need to wait for all packets to be _acked_.\nDisconnect is not commonly used, disallow it.\n\nThe immediate problem syzbot run into is the warning in the strp,\nbut that's just the easiest bug to trigger:\n\n WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n Call Trace:\n \n tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363\n tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043\n inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678\n sock_recvmsg_nosec net/socket.c:1023 [inline]\n sock_recvmsg+0x109/0x280 net/socket.c:1045\n __sys_recvfrom+0x202/0x380 net/socket.c:2237", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.135", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2025-37756" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/7bdcf5bc35ae59fc4a0fa23276e84b4d1534a3cf" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/ac91c6125468be720eafde9c973994cb45b61d44" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f3ce4d3f874ab7919edca364c147ac735f9f1d04" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/2bcad8fefcecdd5f005d8c550b25d703c063c34a" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/9fcbca0f801580cbb583e9cb274e2c7fbe766ca6" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c665bef891e8972e1d3ce5bbc0d42a373346a2c3" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/8513411ec321942bd3cfed53d5bb700665c67d86" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5071a1e606b30c0c11278d3c6620cd6a24724cf6" } ], "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": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerability is triggered by the socket owner issuing `connect(fd, AF_UNSPEC)` followed by `recvmsg()` on their own kTLS socket; a remote TLS peer has no way to induce a disconnect. The TCP connection can be entirely loopback, so no network access is needed at all.\nAC:L - The sequence (attach TLS ULP, receive one record so the strparser latches `msg_ready` with a borrowed `frag_list`, disconnect, recvmsg) is fully under the attacker's control, single-threaded, and deterministic with no race to win. Heap grooming of the freed `skbuff_head` objects is standard and repeatable since the attacker can retry indefinitely.\nPR:L - `net/tls` contains no `capable()`/`ns_capable()` checks whatsoever, and `setsockopt(TCP_ULP,\"tls\")` plus `TLS_RX` crypto_info are available to any unprivileged user once the tls module is built in or resident. All steps are ordinary socket syscalls on a socket the attacker created.\nUI:N - The attacker performs every step themselves within a single process; no victim action, mount, or file open is involved.\nS:U - The corruption is confined to kernel memory managed by the same kernel security authority; there is no VM, IOMMU, or sandbox boundary crossed.\nC:H - `skb_nsg()`/`skb_to_sgvec()` walk the anchor's dangling `frag_list` into freed `skbuff_head` slab objects, building a scatterlist from attacker-sprayable page pointers; the zero-copy AEAD then writes those kernel bytes into the user's buffer before the tag check fails, and since the attacker chose the RX key/IV they recover the plaintext \u2014 an arbitrary kernel memory read.\nI:H - This is a use-after-free: `tls_strp_msg_hold()` performs `skb_clone()` on freed skbs (refcount writes into reallocated slab memory) and queues clones that are later freed, giving heap corruption and arbitrary-free primitives usable for control-flow hijack.\nA:H - The immediate observable effect is the `WARN_ON` at net/tls/tls_strp.c:486 (a panic under `panic_on_warn`), and the subsequent dereference of freed skb metadata and wild page pointers reliably oopses the kernel." } } }