{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-64124", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-64124" ], "published": "2026-07-19T15:41:06Z", "summary": "net: devmem: reject dma-buf bind with non-page-aligned size or SG length", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: devmem: reject dma-buf bind with non-page-aligned size or SG length\n\nnet_devmem_bind_dmabuf() trusts dmabuf->size and sg_dma_len() to be\nPAGE_SIZE multiples without checking:\n\n - tx_vec is sized dmabuf->size / PAGE_SIZE, and\n net_devmem_get_niov_at() only bounds-checks virt_addr < dmabuf->size\n before indexing tx_vec[virt_addr / PAGE_SIZE]. With size =\n N*PAGE_SIZE + r (1 <= r < PAGE_SIZE), sendmsg() at iov_base =\n N*PAGE_SIZE passes the bound check and reads tx_vec[N] -- one past.\n\n - owner->area.num_niovs = len / PAGE_SIZE while gen_pool_add_owner()\n covers the full byte len, so a non-page-multiple non-final sg\n desyncs num_niovs from the gen_pool region for every later sg, on\n both RX and TX.\n\ndma-buf does not require page-aligned sizes, so the bind path has to\nenforce what its own indexing assumes. Reject both with -EINVAL.\n\nThe size check is TX-only (only tx_vec is sized off dmabuf->size); the\nSG-length check covers both directions.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/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" ], "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" } ] }, "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.35" }, "1:6.18.33-1+rpt1": { "linux_commit": "95b85bebbedcaedfa7ca79116ed38b7376fba412", "upstream_version": "6.18.33", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.35" }, "1:6.18.34-1+rpt1": { "linux_commit": "c8c7494100e99ee05b11aaa4f0588a223a63d1af", "upstream_version": "6.18.34", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.35" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-64124" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/134c517dfa63203287b2aad6558017f42435a02e" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/d5008e4e4ee6b739256b796702a7d1aae1b5c3b4" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/4eb82ba543421e9e38cc14e4e82058b78850df50" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T13:16:28Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 8.8, "cvss_v3_severity": "High", "scenario": "AV:L - Exploitation requires local syscalls\u2014NETLINK_GENERIC netdev bind operations and sendmsg/recvmsg on TCP sockets\u2014not remote packet delivery. Network traffic can trigger RX allocations only after a local bind with a malformed dmabuf.\nAC:L - The attacker fully controls dmabuf size/SG layout at bind time and the virtual offset passed via sendmsg iovec bases, allowing reliable out-of-bounds indexing without races or victim-dependent timing.\nPR:L - TX bind intentionally lacks admin-perm; RX bind requires CAP_NET_ADMIN, which is obtainable in user namespaces via unshare. No real-root privileges are needed, only a local authorized user on a devmem-capable system.\nUI:N - No victim interaction is required; the attacker triggers the bug through their own netlink bind and socket operations.\nS:C - Corrupted net_iov metadata can program incorrect DMA addresses for NIC DMA operations, potentially impacting device memory outside the kernel's security authority\u2014a DMA boundary crossing inherent to the devmem subsystem.\nC:H - Out-of-bounds read of tx_vec leaks adjacent kernel heap contents (kernel pointers), and heap corruption from misindexed niovs arrays can be leveraged for arbitrary memory disclosure.\nI:H - Out-of-bounds writes to the niovs array corrupt adjacent kernel heap objects, and use of attacker-influenced pointers in skb fragment setup enables memory corruption exploitable for control-flow hijacking.\nA:H - Dereferencing corrupted net_iov pointers or corrupting heap metadata via out-of-bounds access can cause kernel oops, panic, or hang during TX sendmsg or RX packet processing." } } }