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
[email protected]