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

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Aug 18, 2026 at 03:19:51PM +0800, 潘煜杭 wrote:
> Hello Greg and maintainers,
> 
> I apologize for the mistake in my previous submission. I sent the updated
> patch directly to Greg as an attachment, but I did not post it to the
> linux-media mailing list. Therefore, there is no lore.kernel.org link for
> that submission.
> 
> The patch fixes a potential NULL pointer dereference in the saa7134 ALSA
> IRQ path. If the ALSA capture stream has not been successfully prepared,
> dev->dmasound.substream may be NULL when a DMA sound interrupt is handled.

And how can that happen?  Is it something that a user can trigger or is
this only due to fault-injection testing?

> The handler can then call snd_pcm_stop_xrun() with a NULL substream and
> crash the kernel in IRQ context.
> 
> The patch ignores DMA sound interrupts until the ALSA substream and the
> required buffer parameters have been initialized.
> 
> The v2 patch was previously tested on a clean tree at commit
> 6779b50faa56 with:
> 
>   git am --3way 0001-media-saa7134-alsa-avoid-IRQ-handling-before-capture.patch
>   ./scripts/checkpatch.pl --strict 0001-media-saa7134-alsa-avoid-IRQ-handling-before-capture.patch
>   make M=drivers/media/pci/saa7134 modules
> 
> The patch applied successfully, checkpatch reported zero errors and zero
> warnings, and the saa7134 module build succeeded.
> 
> Could you please review this patch and let me know whether an updated
> version is required? I would also appreciate guidance on whether this issue
> is confirmed as a security bug and whether a CVE should be requested.

Again, can a user trigger this?

And please read the documentation for how CVEs are assigned (hint, this
isn't where that happens...)

thanks,

greg k-h