Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Eager PTE insertion via `vm_insert_page()` during the `mmap` callback uses a stale `vm_page_prot`, inadvertently granting userspace write access to the kernel-owned ALSA status page. --
commit 31ad2114dee595c7dfa978aa004add8157e4aa43 Author: Lorenzo Stoakes (ARM) <[email protected]> ALSA: pcm: use vm_insert_page() to map PCM status page This commit replaces the fault handler for the PCM status page mapping with a direct vm_insert_page() call during the mmap callback. It also ensures the VM_MAYWRITE flag is cleared so the status page remains kernel-owned and read-only to userspace. > diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c > index 62324282fcae9..37a157d558325 100644 > --- a/sound/core/pcm_native.c > +++ b/sound/core/pcm_native.c [ ... ] > @@ -3760,39 +3760,26 @@ static __poll_t snd_pcm_poll(struct file *file, > poll_table *wait) [ ... ] > -static int snd_pcm_mmap_status(struct snd_pcm_substream *substream, struct > file *file, > - struct vm_area_struct *area) > +static int snd_pcm_mmap_status(struct snd_pcm_substream *substream, struct > file *file, > + struct vm_area_struct *vma) > { [ ... ] > - vm_flags_mod(area, VM_DONTEXPAND | VM_DONTDUMP, > + > + vm_flags_mod(vma, VM_DONTEXPAND | VM_DONTDUMP, > VM_WRITE | VM_MAYWRITE); > > - return 0; > + runtime = substream->runtime; > + page = virt_to_page(runtime->status); > + return vm_insert_page(vma, vma->vm_start, page); [Severity: High] Does this eager PTE insertion inadvertently grant userspace write access to the kernel-owned ALSA status page? When a user requests mmap with PROT_WRITE, the core MM's mmap_region() initializes vma->vm_page_prot with hardware write permissions. This driver callback clears VM_WRITE and VM_MAYWRITE from vma->vm_flags using vm_flags_mod(). However, vm_flags_mod() modifies only the software VMA flags and does not update vma->vm_page_prot. The callback then eagerly populates the page table by calling vm_insert_page(). This function reads the unmodified, still-writable vma->vm_page_prot and installs a writable hardware PTE. Only after the driver callback returns does the core MM invoke vma_set_page_prot() via __mmap_complete() to recalculate the protection based on the new flags. But by then, the PTE is already populated with the stale writable protection, allowing kernel state corruption. > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/20260908-b4-mmap-prepare-vma-flag-sanify-v1-0-dacf19cce...@kernel.org?part=12
