Re: [PATCH] ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF

[Takashi Iwai <tiwai@suse.de>]

On Mon, 31 Aug 2026 06:55:06 +0200,
Yilin Zhang wrote:
> 
> snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation
> with an mmap_count check performed under the PCM stream lock, but the
> lock is released long before the buffer is actually freed:
> snd_pcm_sync_stop(), constraint refinement and do_free_pages() all
> happen in between.  snd_pcm_mmap_data(), on the other hand, takes no
> lock at all: it validates against the old buffer's state and
> dma_bytes, remaps its pages into the VMA, and only then increments
> mmap_count.
> 
> A concurrent mmap() can therefore slip in between the check and the
> free.  remap_pfn_range() installs writable PTEs for the old buffer's
> pages without taking page references, and the subsequent
> do_free_pages() returns those pages to the page allocator while the
> VMA still maps them.  This leaves a stale, writable mapping of freed
> pages: a page-level use-after-free that can be leveraged for local
> privilege escalation.
> 
> Make snd_pcm_mmap_data() participate in the buffer-access scheme
> introduced for hw_params/hw_free: acquire runtime->buffer_accessing
> before validating and remapping, and release it afterwards.  Buffer
> reallocation already fails with -EBUSY while accessors are active,
> and the mmap side now fails with -EBUSY while a reallocation is in
> progress, so the validate/remap sequence and the check/free sequence
> can no longer interleave.
> 
> A reproducer that turns this race into a stale writable mapping of
> the freed DMA buffer pages is available on request.
> 
> Reported-by: Kimi Security Team <bug-report@moonshot.ai>
> Fixes: 92ee3c60ec9f ("ALSA: pcm: Fix races among concurrent hw_params and hw_free calls")
> Signed-off-by: Yilin Zhang <yilinzhang@moonshot.ai>

Applied now.  Thanks.


Takashi