CVE-2025-37805: sound/virtio: Fix cancel_sync warnings on uninitialized work_structs

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

sound/virtio: Fix cancelsync warnings on uninitialized workstructs

Betty reported hitting the following warning:

[ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182 ... [ 8.713282][ T221] Call trace: [ 8.713365][ T221] flushwork+0x8d0/0x914 [ 8.713468][ T221] cancelworksync+0xac/0xfc [ 8.713570][ T221] cancelworksync+0x24/0x34 [ 8.713667][ T221] virtsndremove+0xa8/0xf8 [virtiosnd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.713868][ T221] virtsndprobe+0x48c/0x664 [virtiosnd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.714035][ T221] virtiodevprobe+0x28c/0x390 [ 8.714139][ T221] reallyprobe+0x1bc/0x4c8 ...

It seems we're hitting the error path in virtsndprobe(), which triggers a virtsndremove() which iterates over the substreams calling cancelworksync() on the elapsedperiod workstruct.

Looking at the code, from earlier in: virtsndprobe()->virtsndbuilddevs()->virtsndpcmparsecfg()

We set snd->nsubstreams, allocate the snd->substreams, and if we then hit an error on the info allocation or something in virtsndctlqueryinfo() fails, we will exit without having initialized the elapsedperiod workstruct.

When that error path unwinds we then call virtsndremove() which as long as the substreams array is allocated, will iterate through calling cancelworksync() on the uninitialized work struct hitting this warning.

Takashi Iwai suggested this fix, which initializes the substreams structure right after allocation, so that if we hit the error paths we avoid trying to cleanup uninitialized data.

Note: I have not yet managed to reproduce the issue myself, so this patch has had limited testing.

Feedback or thoughts would be appreciated!