{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-64550", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-64550" ], "published": "2026-07-27T20:10:44Z", "summary": "net: qualcomm: rmnet: validate MAP frame length before ingress parsing", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: qualcomm: rmnet: validate MAP frame length before ingress parsing\n\nWhen ingress deaggregation is disabled, rmnet_map_ingress_handler() passes\nthe skb straight to __rmnet_map_ingress_handler(), skipping the length\nvalidation that rmnet_map_deaggregate() performs on the aggregated path.\nThe parser then dereferences the MAP header and csum header/trailer based on\nthe on-wire pkt_len without checking skb->len, so a short frame is read out\nof bounds:\n\n BUG: KASAN: slab-out-of-bounds in rmnet_map_checksum_downlink_packet\n Read of size 1 at addr ffff88801118ed00 by task exploit/147\n Call Trace:\n ...\n rmnet_map_checksum_downlink_packet (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:413)\n __rmnet_map_ingress_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:96)\n rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:129)\n __netif_receive_skb_core.constprop.0 (net/core/dev.c:6089)\n netif_receive_skb (net/core/dev.c:6460)\n tun_get_user (drivers/net/tun.c:1955)\n tun_chr_write_iter (drivers/net/tun.c:2001)\n vfs_write (fs/read_write.c:688)\n ksys_write (fs/read_write.c:740)\n do_syscall_64 (arch/x86/entry/syscall_64.c:94)\n ...\n\nFactor that validation out of rmnet_map_deaggregate() into\nrmnet_map_validate_packet_len() and run it on the no-aggregation path too.\nThe MAP header is bounds-checked first, since this path can receive a frame\nshorter than the header.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/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.178", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-64550" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/ed25befc8c36f896b5878f9078faddb67fd7e2d0" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a54d76d176e50d2fdbd39b7231efe256170339e4" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/00f4c366dbca16a40772c3b7ec2d8cba839e9724" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/3868c3244369ab709a90c9aad7534d406009b824" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/14eb0c9491385d5361a292ea4974aec0e6887299" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/1b12612c367e4be9b0814c0468e7e687835315b4" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/231a8a4b76cb1b1827b3b19d7b3603642f5aaaef" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f0f1887a9e30712a1df03e152dce6fb91344b1f3" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-17T05:24:08Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.3, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerability is reached by `write()` to a tun fd owned by the attacker, exactly as in the reporter's KASAN trace (`tun_chr_write_iter` \u2192 `netif_receive_skb` \u2192 `rmnet_rx_handler`), requiring a local account. Although rmnet can be stacked on an Ethernet device (commit 74692caf1b0b), the universally available and demonstrated vector is local.\nAC:L - Every precondition is attacker-chosen \u2014 the `data_format` flags (deaggregation off, CKSUMV4 on) via `IFLA_RMNET_FLAGS`, the frame length, and the `pkt_len`/`pad` fields that select the OOB offset \u2014 with no race, timing, or uncontrolled memory-layout dependency. The trigger is a single deterministic `write()` that can be repeated indefinitely to sweep offsets.\nPR:L - Only an unprivileged local account is needed: `/dev/net/tun` is world-accessible, and both `TUNSETIFF` and `rtnl_newlink` gate on namespace-scoped `ns_capable`/`netlink_net_capable(CAP_NET_ADMIN)`, which `unshare -Urn` grants without real root.\nUI:N - The attacker creates the tun device, the rmnet link, and writes the malformed frame entirely on its own. No victim action or pre-existing configuration is required.\nS:U - The out-of-bounds access and its consequences are confined to kernel memory within the same security authority. No VM, IOMMU, or sandbox boundary is crossed.\nC:H - This is an attacker-positioned read up to 65535 bytes past a small slab object, and the result is disclosed back to userspace through the unprivileged rmnet ethtool counters \u2014 because the pseudo-header checksum is computed from the attacker's own IP header, the exact 16-bit heap word at a chosen offset is recoverable in a few probes, yielding a precise heap-read primitive for KASLR bypass and secret disclosure.\nI:L - There is no arbitrary write, but out-of-bounds data determines `skb->ip_summed = CHECKSUM_UNNECESSARY`, causing packets whose checksums were never validated to be accepted by the IP stack as verified. On the MAP-command path `rmnet_map_send_ack()` also writes `cmd->cmd_type` past the end of a short frame after `skb_trim()` underflows into a no-op.\nA:H - A 64 KB overshoot from a small kmalloc object can land on an unmapped page (guard pages, DEBUG_PAGEALLOC/hardened allocators, memory-region edges), faulting in kernel context and producing an oops; on the real WWAN receive path (ipa/qmi_wwan/mhi_net NAPI) this executes in softirq, where the fault is a panic. KASAN builds abort immediately, as the reporter's trace shows." } } }