{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-74641", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-74641" ], "published": "2026-08-22T15:32:12Z", "summary": "ALSA: usx2y: bound the hwdep mmap fault offset", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usx2y: bound the hwdep mmap fault offset\n\nsnd_us428ctls_vm_fault() turns the faulting page offset into a kernel\naddress with no bound of any kind:\n\n\toffset = vmf->pgoff << PAGE_SHIFT;\n\tvaddr = (char *)(...)->us428ctls_sharedmem + offset;\n\tpage = virt_to_page(vaddr);\n\tget_page(page);\n\tvmf->page = page;\n\n\treturn 0;\n\nsnd_us428ctls_mmap() checks only the length of the mapping, never the\noffset, and us428ctls_sharedmem is a single page from\nalloc_pages_exact(). For a character device file_mmap_size_max()\nreturns ULONG_MAX, so the mm layer imposes no ceiling either. Every page\noffset above zero resolves to a struct page outside the object, and the\nhandler installs it into the caller's address space read-write; the vma\nis not marked read-only.\n\nThe caller picks the page frame with a single mmap() argument and gets\nread-write access to a page of kernel memory it does not own; an offset\nthat lands in an unpopulated vmemmap region oopses instead.\n\nA process that can open the hwdep node of an attached US-X2Y reaches\nthis after loading the FPGA image through the same node; no capability\ncheck is involved.\n\nOn 7.2.0-rc5 (arm64), mmap() with a large offset:\n\n Unable to handle kernel paging request at virtual address fffffdffc45d5ac8\n pc : snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y]\n Call trace:\n snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y]\n __do_fault\n __handle_mm_fault\n handle_mm_fault\n el0_da\n\nReject any offset outside the shared region. The pcm hwdep handler in\nusx2yhwdeppcm.c computes its address the same way and needs the same\nbound.\n\nDiscovered by XBOW, triaged by Baul Lee ", "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.183", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-74641" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/ad6fedea65c6e90eda00d716c8bf20cdc437ed10" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/10a87401fb3148c388e55df0148295b3b137da07" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/34ab56ed854baa73a731cfd99af689f0b1bac444" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/4208db2453e1ea71b8048a5b7802360cb29a53f1" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f613b4a2d87247b51a1b2b330f2e083a454125f2" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f75d6f61f0d9c5c1ea725104014e10d26d1e3a00" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5bf5ccddf00b59f1e3ea7e65d76a5f5b5c21cc2e" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/2ca1eea3cd17930daffe9e429a7c89232036ec24" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-25T05:42:41Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - Exploitation requires local mmap() on the ALSA hwdep character device (/dev/snd/hwC*D*); the path is open\u2192SNDRV_HWDEP_IOCTL_DSP_LOAD\u2192mmap\u2192snd_us428ctls_vm_fault, with no network or remote packet handler involved.\nAC:L - The attacker fully controls the mmap() page offset (vmf->pgoff); any offset beyond the single-page shared buffer deterministically maps an attacker-chosen kernel page read-write or oopses, with no race or uncontrollable memory-layout dependency.\nPR:L - The driver performs no capability checks on hwdep open, ioctl, or mmap; any unprivileged local user who can access the hwdep node (typically via the audio group on desktop distros) can reach the fault handler after loading the FPGA image.\nUI:N - All exploitation steps\u2014opening the hwdep node, loading FPGA firmware via DSP_LOAD ioctl, and mmap with a crafted offset\u2014are performed by the attacker; no discretionary victim action beyond the device being present in the environment is required.\nS:U - Impact is arbitrary read/write of host kernel memory leading to local privilege escalation within the same kernel security authority; it does not cross a VM, container, or IOMMU security boundary.\nC:H - Unbounded pgoff arithmetic maps arbitrary kernel struct pages into the attacker's address space; the VMA is not read-only, giving attacker-controlled read access to any reachable kernel page selected via the mmap offset.\nI:H - The same unbounded mmap fault path installs attacker-chosen kernel pages into a read-write userspace mapping, enabling arbitrary kernel memory writes and heap corruption primitives suitable for privilege escalation or code execution.\nA:H - Large mmap offsets dereference unpopulated vmemmap regions causing kernel paging faults and oops (demonstrated on arm64); arbitrary kernel page writes can also panic the system or destabilize the kernel." } } }