Subject: Re: [PATCH v2] media: saa7134-alsa: avoid IRQ handling before capture is prepared

Subject: Re: [PATCH v2] media: saa7134-alsa: avoid IRQ handling before capture is prepared

[潘煜杭]

Hello Greg,

Thank you for the clarification.

I apologize for previously asking the maintainers about CVE assignment
through the wrong channel.

I reviewed the original test setup. The saa7134 driver source on the
crashing path was not modified. The userspace program issued valid V4L2
operations, including VIDIOC_REQBUFS, VIDIOC_QUERYBUF, VIDIOC_QBUF,
VIDIOC_STREAMON, VIDIOC_DQBUF, and VIDIOC_STREAMOFF.

The reproducer does not require root privileges or a physical saa7134
card. It runs in QEMU, where the saa7134 device is emulated by the SFP
device model. The normal saa7134 and saa7134_alsa modules are loaded,
and the crash is triggered through normal userspace V4L2 ioctl() calls.

The driver submits a DMA request, after which the emulated device model
automatically generates the corresponding DMA-related interrupt. The
relevant test output included:

  INFO:Trigger IRQ after setting DMA
  kcov-remote-bridge: async entry

Thus, an unprivileged user can trigger the NULL pointer dereference through
normal V4L2 operations in the QEMU saa7134 emulation environment. I have
not separately verified whether the same interrupt ordering can occur on a
physical saa7134 card.

The crash itself is confirmed by the following path:

  saa7134_irq()
    -> saa7134_alsa_irq()
    -> saa7134_irq_alsa_done()
    -> snd_pcm_stop_xrun(NULL)

The crash log shows RDI == 0 in snd_pcm_stop_xrun(), followed by a KASAN
NULL-pointer report and a fatal exception in interrupt context.

Regards,

Yuhang Pan
panyuhang@hdu.edu.cn

Re: Subject: Re: [PATCH v2] media: saa7134-alsa: avoid IRQ handling before capture is prepared

[Greg KH]

On Fri, Aug 21, 2026 at 05:20:53PM +0800, 潘煜杭 wrote:
> 
> Hello Greg,
> 
> Thank you for the clarification.
> 
> I apologize for previously asking the maintainers about CVE assignment
> through the wrong channel.
> 
> I reviewed the original test setup. The saa7134 driver source on the
> crashing path was not modified. The userspace program issued valid V4L2
> operations, including VIDIOC_REQBUFS, VIDIOC_QUERYBUF, VIDIOC_QBUF,
> VIDIOC_STREAMON, VIDIOC_DQBUF, and VIDIOC_STREAMOFF.
> 
> The reproducer does not require root privileges or a physical saa7134
> card. It runs in QEMU, where the saa7134 device is emulated by the SFP
> device model. The normal saa7134 and saa7134_alsa modules are loaded,
> and the crash is triggered through normal userspace V4L2 ioctl() calls.
> 
> The driver submits a DMA request, after which the emulated device model
> automatically generates the corresponding DMA-related interrupt. The
> relevant test output included:
> 
>   INFO:Trigger IRQ after setting DMA
>   kcov-remote-bridge: async entry
> 
> Thus, an unprivileged user can trigger the NULL pointer dereference through
> normal V4L2 operations in the QEMU saa7134 emulation environment. I have
> not separately verified whether the same interrupt ordering can occur on a
> physical saa7134 card.

Perhaps the emulated driver is not correct?  Try it on real hardware to
see?

> The crash itself is confirmed by the following path:
> 
>   saa7134_irq()
>     -> saa7134_alsa_irq()
>     -> saa7134_irq_alsa_done()
>     -> snd_pcm_stop_xrun(NULL)
> 
> The crash log shows RDI == 0 in snd_pcm_stop_xrun(), followed by a KASAN
> NULL-pointer report and a fatal exception in interrupt context.

So do you have a proposed fix for this issue?  That would be best as I
really don't have much context here, sorry.

thanks,

greg k-h