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:   Thu, 17 May 2018 00:09:55 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Ben Hutchings <ben.hutchings@...ethink.co.uk>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        syzbot+8e62ff4e07aa2ce87826@...kaller.appspotmail.com
Subject: Re: [PATCH 4.4 53/97] ALSA: pcm: Fix UAF at PCM release via PCM timer access

On Wed, 16 May 2018 22:51:47 +0200,
Ben Hutchings wrote:
> 
> On Sun, 2018-04-22 at 15:53 +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Takashi Iwai <tiwai@...e.de>
> > 
> > commit a820ccbe21e8ce8e86c39cd1d3bc8c7d1cbb949b upstream.
> >
> > The PCM runtime object is created and freed dynamically at PCM stream
> > open / close time.  This is tracked via substream->runtime, and it's
> > cleared at snd_pcm_detach_substream().
> > 
> > The runtime object assignment is protected by PCM open_mutex, so for
> > all PCM operations, it's safely handled.  However, each PCM substream
> > provides also an ALSA timer interface, and user-space can access to
> > this while closing a PCM substream.  This may eventually lead to a
> > UAF, as snd_pcm_timer_resolution() tries to access the runtime while
> > clearing it in other side.
> > 
> > Fortunately, it's the only concurrent access from the PCM timer, and
> > it merely reads runtime->timer_resolution field.  So, we can avoid the
> > race by reordering kfree() and wrapping the substream->runtime
> > clearance with the corresponding timer lock.
> [...]
> 
> This seems to depend on:
> 
> commit f65e0d299807d8a11812845c972493c3f9a18e10
> Author: Takashi Iwai <tiwai@...e.de>
> Date:   Wed Feb 10 12:47:03 2016 +0100
> 
>     ALSA: timer: Call notifier in the same spinlock
> 
> (But I'm not totally convinced that snd_pcm_timer_resolution() is
> always called with the timer lock held, even after that.)

Indeed, there seem more codes calling the callback without the lock.
I'll send the fix patches.


thanks,

Takashi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ