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]

Message-ID: <s5hmurunv13.wl-tiwai@suse.de>
Date:   Thu, 04 Oct 2018 07:24:56 +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 Thu, 04 Oct 2018 05:08:45 +0200,
Jia-Ju Bai wrote:
> 
> Thanks for the reply :)
> 
> 
> On 2018/10/3 23:54, Takashi Iwai wrote:
> > 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.
> 
> How about the case that playback and capture are performed concurrently?
> Namely, snd_trident_hw_free() is called for playback, and the
> interrupt is generated for capture.

They are different substreams, hence it won't pick up the substream
object.

> > And the hardware is very old, I bet only a handful people still using
> > in the whole world :)
> 
> I have this hardware, so I am the one of these handful people ;)

Wow, that's fun.  Then we can really fix the issue, if any.
Did you actually hit any relevant bug?


thanks,

Takashi