The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Baul Lee <baul.lee@xbow.com>
Cc: perex@perex.cz, tiwai@suse.com, linux-sound@vger.kernel.org,
	linux-kernel@vger.kernel.org, federico.kirschbaum@xbow.com,
	stable@vger.kernel.org
Subject: Re: [PATCH] ALSA: usx2y: bound the hwdep mmap fault offset
Date: Wed, 05 Aug 2026 09:36:13 +0200	[thread overview]
Message-ID: <87ik5pggsy.wl-tiwai@suse.de> (raw)
In-Reply-To: <20260805013445.38283-1-baul.lee@xbow.com>

On Wed, 05 Aug 2026 03:34:45 +0200,
Baul Lee wrote:
> 
> snd_us428ctls_vm_fault() turns the faulting page offset into a kernel
> address with no bound of any kind:
> 
> 	offset = vmf->pgoff << PAGE_SHIFT;
> 	vaddr = (char *)(...)->us428ctls_sharedmem + offset;
> 	page = virt_to_page(vaddr);
> 	get_page(page);
> 	vmf->page = page;
> 
> 	return 0;
> 
> snd_us428ctls_mmap() checks only the length of the mapping, never the
> offset, and us428ctls_sharedmem is a single page from
> alloc_pages_exact().  For a character device file_mmap_size_max()
> returns ULONG_MAX, so the mm layer imposes no ceiling either.  Every page
> offset above zero resolves to a struct page outside the object, and the
> handler installs it into the caller's address space read-write; the vma
> is not marked read-only.
> 
> The caller picks the page frame with a single mmap() argument and gets
> read-write access to a page of kernel memory it does not own; an offset
> that lands in an unpopulated vmemmap region oopses instead.
> 
> A process that can open the hwdep node of an attached US-X2Y reaches
> this after loading the FPGA image through the same node; no capability
> check is involved.
> 
> On 7.2.0-rc5 (arm64), mmap() with a large offset:
> 
>   Unable to handle kernel paging request at virtual address fffffdffc45d5ac8
>   pc : snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y]
>   Call trace:
>    snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y]
>    __do_fault
>    __handle_mm_fault
>    handle_mm_fault
>    el0_da
> 
> Reject any offset outside the shared region.  The pcm hwdep handler in
> usx2yhwdeppcm.c computes its address the same way and needs the same
> bound.
> 
> Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: Federico Kirschbaum <federico.kirschbaum@xbow.com>
> Reported-by: Baul Lee <baul.lee@xbow.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Baul Lee <baul.lee@xbow.com>

Applied now.  Thanks.


Takashi

      reply	other threads:[~2026-08-05  7:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05  1:34 [PATCH] ALSA: usx2y: bound the hwdep mmap fault offset Baul Lee
2026-08-05  7:36 ` Takashi Iwai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ik5pggsy.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=baul.lee@xbow.com \
    --cc=federico.kirschbaum@xbow.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=stable@vger.kernel.org \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox