[PATCH] ALSA: pcm: Don't WARN on NULL dma_area in the default mmap fault handler

[PATCH] ALSA: pcm: Don't WARN on NULL dma_area in the default mmap fault handler

[Dmitriy Chumachenko]

During fuzz testing, the following issue was discovered.

WARNING: CPU: 2 PID: 1734 at sound/core/pcm_native.c:3835 
snd_pcm_mmap_data_fault+0x47f/0x530 sound/core/pcm_native.c:3835

Modules linked in:
CPU: 2 PID: 1734 Comm: syz.1.352 Not tainted 6.1.187-syzkaller-00593-g063a81552262 #0
RIP: 0010:snd_pcm_mmap_data_fault+0x47f/0x530 sound/core/pcm_native.c:3835

Call Trace:
 <TASK>
 __do_fault+0x10d/0x480 mm/memory.c:4280
 do_cow_fault mm/memory.c:4661 [inline]
 do_fault+0xa7a/0x1100 mm/memory.c:4762
 handle_pte_fault mm/memory.c:5031 [inline]
 __handle_mm_fault+0xdf3/0x2e40 mm/memory.c:5173
 handle_mm_fault+0x2da/0xa60 mm/memory.c:5294
 do_user_addr_fault+0x4aa/0x1050 arch/x86/mm/fault.c:1338
 handle_page_fault arch/x86/mm/fault.c:1429 [inline]
 exc_page_fault+0x98/0x1b0 arch/x86/mm/fault.c:1482
 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:608

snd_pcm_mmap_data_fault() guards the default RAM-buffer path with
WARN_ON_ONCE(!runtime->dma_area). As commit d2913a07d903 notes, a driver
may allow mmap before dma_area is set up, so this state is reachable from
user space: mmap the PCM data region and fault it while the buffer is not
allocated. The WARN then fires on a user-triggerable path and panics a
kernel with panic_on_warn.

Drop the WARN; the NULL check and VM_FAULT_SIGBUS return stay, which is
the correct silent handling.

Fixes: d2913a07d903 ("ALSA: pcm: Add sanity NULL check for the default mmap fault handler")
Signed-off-by: Dmitriy Chumachenko <Dmitry.Chumachenko@cyberprotect.ru>
---
 sound/core/pcm_native.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index fcb5f176f0df..dd640d90f6a3 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3832,7 +3832,7 @@ static vm_fault_t snd_pcm_mmap_data_fault(struct vm_fault *vmf)
 	if (substream->ops->page)
 		page = substream->ops->page(substream, offset);
 	else if (!snd_pcm_get_dma_buf(substream)) {
-		if (WARN_ON_ONCE(!runtime->dma_area))
+		if (!runtime->dma_area)
 			return VM_FAULT_SIGBUS;
 		page = virt_to_page(runtime->dma_area + offset);
 	} else
-- 
2.49.0

Re: [PATCH] ALSA: pcm: Don't WARN on NULL dma_area in the default mmap fault handler

[Takashi Iwai]

On Fri, 30 Oct 2026 12:25:02 +0100,
Dmitriy Chumachenko wrote:
> 
> During fuzz testing, the following issue was discovered.
> 
> WARNING: CPU: 2 PID: 1734 at sound/core/pcm_native.c:3835 
> snd_pcm_mmap_data_fault+0x47f/0x530 sound/core/pcm_native.c:3835
> 
> Modules linked in:
> CPU: 2 PID: 1734 Comm: syz.1.352 Not tainted 6.1.187-syzkaller-00593-g063a81552262 #0
> RIP: 0010:snd_pcm_mmap_data_fault+0x47f/0x530 sound/core/pcm_native.c:3835
> 
> Call Trace:
>  <TASK>
>  __do_fault+0x10d/0x480 mm/memory.c:4280
>  do_cow_fault mm/memory.c:4661 [inline]
>  do_fault+0xa7a/0x1100 mm/memory.c:4762
>  handle_pte_fault mm/memory.c:5031 [inline]
>  __handle_mm_fault+0xdf3/0x2e40 mm/memory.c:5173
>  handle_mm_fault+0x2da/0xa60 mm/memory.c:5294
>  do_user_addr_fault+0x4aa/0x1050 arch/x86/mm/fault.c:1338
>  handle_page_fault arch/x86/mm/fault.c:1429 [inline]
>  exc_page_fault+0x98/0x1b0 arch/x86/mm/fault.c:1482
>  asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:608
> 
> snd_pcm_mmap_data_fault() guards the default RAM-buffer path with
> WARN_ON_ONCE(!runtime->dma_area). As commit d2913a07d903 notes, a driver
> may allow mmap before dma_area is set up, so this state is reachable from
> user space: mmap the PCM data region and fault it while the buffer is not
> allocated. The WARN then fires on a user-triggerable path and panics a
> kernel with panic_on_warn.
> 
> Drop the WARN; the NULL check and VM_FAULT_SIGBUS return stay, which is
> the correct silent handling.
> 
> Fixes: d2913a07d903 ("ALSA: pcm: Add sanity NULL check for the default mmap fault handler")
> Signed-off-by: Dmitriy Chumachenko <Dmitry.Chumachenko@cyberprotect.ru>

The WARN_ON() was put there because it shouldn't happen, and dropping
WARN_ON() is likely an incorrect "solution".

Could you rather investigate how this is triggered (under which
condition with which driver)?  That should be addressed instead of
just silencing it.


thanks,

Takashi