CVE-2026-89880: media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure

In the Linux kernel, the following vulnerability has been resolved:

media: rtl2832sdr: release URBs and stream buffers on startstreaming() failure

rtl2832sdrstartstreaming() calls rtl2832sdrallocstreambufs(), rtl2832sdrallocurbs() and rtl2832sdrsubmiturbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When allocurbs() succeeds but submiturbs() fails, or when allocurbs() itself returns -ENOMEM after allocstreambufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOCSTREAMON:

1) rtl2832sdrallocstreambufs() unconditionally resets dev->bufnum to 0 and overwrites dev->buflist[]/dev->dmaaddr[], permanently leaking the coherent DMA memory allocated by the previous attempt.

2) rtl2832sdrallocurbs() never resets dev->urbsinitialized and only increments it. After a second successful pass urbsinitialized can exceed MAXBULKBUFS, so the subsequent rtl2832sdrfreeurbs() walks from urbsinitialized - 1 down to 0 and reads past the end of dev->urblist[], passing garbage pointers to usbfreeurb().

Mirror the teardown that stopstreaming() already performs: on the error path call rtl2832sdrfreeurbs() and rtl2832sdrfreestreambufs() before unlocking. Both helpers are idempotent (freeurbs kills and zeros urbsinitialized; freestreambufs is gated on URBBUF and clears the bufnum counter), so partial-failure paths and the no-allocation paths remain safe.

Issue identified by automated review of the INV-003 series at https://sashiko.dev/