Re: Subject: [PATCH v2] media: saa7134-alsa: avoid IRQ handling before capture is prepared
Greg KH <[email protected]>
| Newsgroups | org.kernel.vger.linux-media |
|---|---|
| Message-ID | <2026081858-decorated-persuader-a6e0@gregkh> |
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