{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-90051", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-90051" ], "published": "2026-09-17T16:10:40Z", "summary": "tcp: reject non zerocopy devmem tx", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: reject non zerocopy devmem tx\n\nDevmem tcp tx doesn't work without zero-copy, however it's not currently\nenforced if NETIF_F_SG isn't present. In this case, tcp_sendmsg_locked()\nwill try the copy path and try to copy data from an iovec which consists\nof offsets into the dma-buf and would normally fail. Moreover,\nd9c56501c72fd (\"net: tcp: block mixing readable and unreadable frags\")\nrelies on that and assumes that the devmem binding is present IFF we're\nusing the zero-copy path, which can be used to mix net-iov and pages in\na single skb, and break invariants. Let's reject devmem tx without\nzero-copy.\n\nNote, the parameter check the patch is modifying is too loose, we can\ncreate an io_uring request with dmabuf_id and all ZC flags, but which\nwon't have the binding. We replace it with stricter validation.", "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:13", "name": "linux" }, "versions": [ "1:6.18.29-1+rpt1", "1:6.18.33-1+rpt1", "1:6.18.34-1+rpt1", "1:6.18.39-1+rpt1", "1:6.18.50-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.18.29+rpt-rpi-2712", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v6", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v7", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8-rt", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-2712", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v6", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v7", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8-rt", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-2712", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v6", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v7", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8-rt", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-2712", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v6", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v7", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8-rt", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-2712", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v6", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v7", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v8", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v8-rt", "binary_version": "1:6.18.50-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.18.29-1+rpt1": { "linux_commit": "66318c5b5cd8145a662303af12ed39ac07eb27cc", "upstream_version": "6.18.29", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.33-1+rpt1": { "linux_commit": "95b85bebbedcaedfa7ca79116ed38b7376fba412", "upstream_version": "6.18.33", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.34-1+rpt1": { "linux_commit": "c8c7494100e99ee05b11aaa4f0588a223a63d1af", "upstream_version": "6.18.34", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.39-1+rpt1": { "linux_commit": "60ea684a8ace97bb0db1a16e20753bdd6ab371ff", "upstream_version": "6.18.39", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.50-1+rpt1": { "linux_commit": "cff533aec2fa601846766b32ff57204e0a61bed7", "upstream_version": "6.18.50", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-90051" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/2151b2bcf6fcec52665f606eed20da068447f0b7" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b04326c7927af7048fd4e730f5770cca350d0a60" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/125755776bc6d4dd53eaf551c87e3d460625d638" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-09-18T17:55:42Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The triggering input is local sendmsg or io_uring IORING_OP_SENDMSG_ZC into tcp_sendmsg_locked(): SO_ZEROCOPY, MSG_ZEROCOPY, and an SCM_DEVMEM_DMABUF cmsg that sets sockc.dmabuf_id. A remote TCP peer never supplies that cmsg or those send flags; it only receives the resulting segments.\nAC:L - The attacker drives both sendmsg calls: a MSG_ZEROCOPY+SCM_DEVMEM_DMABUF send queues net-iov (unreadable) frags, then a later sendmsg with sockc.dmabuf_id while zc==0 (sk_route_caps lacks NETIF_F_SG, so the copy path runs with binding set) appends pages onto that skb. MSG_MORE retains the write-queue tail; no victim race is required.\nPR:L - NETDEV_CMD_BIND_TX has no GENL_ADMIN_PERM, and SO_ZEROCOPY plus __sock_cmsg_send(SCM_DEVMEM_DMABUF) have no capability checks. An unprivileged user can bind a TX dmabuf and reach the zc/binding check in tcp_sendmsg_locked; any extra CAP_NET_ADMIN is only the user-namespace kind.\nUI:N - The attacker enables SO_ZEROCOPY, binds a dmabuf via netdev-genl NETDEV_CMD_BIND_TX, and issues the crafted sendmsg/IORING_OP_SENDMSG_ZC sequence on their own TCP socket; no victim mount, open, or other interactive action is required.\nS:U - Mixing net_iov and page frags corrupts skb/TX processing on the sending host inside tcp_sendmsg_locked and later frag walkers. It does not cross a VM/guest or IOMMU authority; __skb_frag_dma_map still classifies each frag with skb_frag_is_net_iov.\nC:H - A mixed skb keeps skb->unreadable from skb_add_rx_frag_netmem while the zc==0 path adds page frags via skb_fill_page_desc. Walkers such as tcp_md5_hash_skb_data use skb_frag_foreach_page/skb_frag_page() on net_iovs (NULL) and kmap that pointer, enabling kernel memory disclosure.\nI:H - Appending sk_page_frag pages onto a net-iov skb via the zc==0 copy path in tcp_sendmsg_locked is frag-type confusion: TX, refcount, and skb_fill_page_desc versus skb_add_rx_frag_netmem cannot treat mixed backing consistently, which yields corrupted skb metadata and write or control-flow primitives.\nA:H - Mixed readable/unreadable frags blow up down the stack: skb_copy_bits/skb_checksum hit WARN_ON_ONCE(!skb_frags_readable), splice hits WARN_ON_ONCE(!skb_frag_page), and kmap of a NULL net_iov page oopses or panics the kernel." } } }