linux-kernel - Re: [PATCH 0/2] ALSA: pcm: Fix race condition in runtime access

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: <CAJaf1TaZzsPdydcMZMemVSkjRvhYvx7ZxY2JEvExQ56B+MjQLQ@mail.gmail.com>
Date:   Wed, 13 Nov 2019 15:24:41 +0800
From:   Chih-Yang Hsia <paulhsia@...omium.org>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     linux-kernel@...r.kernel.org, Mark Brown <broonie@...nel.org>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org
Subject: Re: [PATCH 0/2] ALSA: pcm: Fix race condition in runtime access

On Wed, Nov 13, 2019 at 2:16 AM Takashi Iwai <tiwai@...e.de> wrote:
>
> On Tue, 12 Nov 2019 18:17:13 +0100,
> paulhsia wrote:
> >
> > Since
> > - snd_pcm_detach_substream sets runtime to null without stream lock and
> > - snd_pcm_period_elapsed checks the nullity of the runtime outside of
> >   stream lock.
> >
> > This will trigger null memory access in snd_pcm_running() call in
> > snd_pcm_period_elapsed.
>
> Well, if a stream is detached, it means that the stream must have been
> already closed; i.e. it's already a clear bug in the driver that
> snd_pcm_period_elapsed() is called against such a stream.
>
> Or am I missing other possible case?
>
>
> thanks,
>
> Takashi
>

In multithreaded environment, it is possible to have to access both
`interrupt_handler` (from irq) and `substream close` (from
snd_pcm_release) at the same time.
Therefore, in driver implementation, if "substream close function" and
the "code section where snd_pcm_period_elapsed() in" do not hold the
same lock, then the following things can happen:

1. interrupt_handler -> goes into snd_pcm_period_elapsed with a valid
sustream pointer
2. snd_pcm_release_substream: call close without blocking
3. snd_pcm_release_substream: call snd_pcm_detache_substream and set
substream->runtime to NULL
4. interrupt_handler -> call snd_pcm_runtime() and crash while
accessing fields in `substream->runtime`

e.g. In intel8x0.c driver for ac97 device,
In driver intel8x0.c, `snd_pcm_period_elapsed` is called after
checking `ichdev->substream` in `snd_intel8x0_update`.
And if a `snd_pcm_release` call from alsa-lib and pass through close()
and run to snd_pcm_detach_substream() in another thread, it's possible
to trigger a crash.
I can reproduce the issue within a multithread VM easily.

My patches are trying to provide a basic protection for this situation
(and internal pcm lock between detach and elapsed), since
- the usage of `snd_pcm_period_elapsed` does not warn callers about
the possible race if the driver does not  force the order for `calling
snd_pcm_period_elapsed` and `close` by lock and
- lots of drivers already have this hidden issue and I can't fix them
one by one (You can check the "snd_pcm_period_elapsed usage" and the
"close implementation" within all the drivers). The most common
mistake is that
  - Checking if the substream is null and call into snd_pcm_period_elapsed
  - But `close` can happen anytime, pass without block and
snd_pcm_detach_substream will be trigger right after it

Best,
Paul

> >
> > paulhsia (2):
> >   ALSA: pcm: Fix stream lock usage in snd_pcm_period_elapsed()
> >   ALSA: pcm: Use stream lock in snd_pcm_detach_substream()
> >
> >  sound/core/pcm.c     | 8 +++++++-
> >  sound/core/pcm_lib.c | 8 ++++++--
> >  2 files changed, 13 insertions(+), 3 deletions(-)
> >
> > --
> > 2.24.0.rc1.363.gb1bccd3e3d-goog
> >