linux-kernel - Re: [BUG] sound: pci: trident: a possible data race

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 03 Oct 2018 17:54:10 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     "Jia-Ju Bai" <baijiaju1990@...il.com>
Cc:     <keescook@...omium.org>, <perex@...ex.cz>,
        <alsa-devel@...a-project.org>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] sound: pci: trident: a possible data race

On Wed, 03 Oct 2018 14:50:25 +0200,
Jia-Ju Bai wrote:
> 
> CPU0:
> snd_trident_hw_free
>     snd_trident_free_voice
>             line 3870: spin_lock_irqsave()
>             line 3881: voice->substream = NULL; [WRITE]
> CPU1:
> snd_trident_interrupt
>     line 3798: snd_pcm_period_elapsed(voice->substream);  [READ]
> 
> As for voice->substream, the WRITE operation in CPU0 is performed
> with holding a spinlock, but the READ operation in CPU1 is performed
> without holding this spinlock, so there may exist a data race.

Thanks for the report.

The actual crash must be very unlikely, almost 0%, though.
snd_trident_hw_free() is called always after the PCM stream gets
stopped via trigger callback, i.e. at the moment, there is no
corresponding interrupt is generated for that voice entry.

And the hardware is very old, I bet only a handful people still using
in the whole world :)

If we really want to be 100% sure, we may call synchronize_irq()
before the NULL-clearing.  But there is no way to test the bug nor
the fix, so it's fairly moot, IMO.

thanks,

Takashi