[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <s5hshyfxt0f.wl-tiwai@suse.de>
Date: Thu, 21 Apr 2016 10:31:28 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: alsa-devel@...a-project.org, Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Jaroslav Kysela <perex@...ex.cz>,
LKML <linux-kernel@...r.kernel.org>,
Alexander Potapenko <glider@...gle.com>,
Kostya Serebryany <kcc@...gle.com>,
syzkaller <syzkaller@...glegroups.com>,
Sasha Levin <sasha.levin@...cle.com>
Subject: Re: sound: use-after-free in snd_timer_interrupt
On Thu, 21 Apr 2016 10:14:10 +0200,
Dmitry Vyukov wrote:
>
> On Wed, Apr 20, 2016 at 12:31 PM, Takashi Iwai <tiwai@...e.de> wrote:
> > On Wed, 20 Apr 2016 10:08:55 +0200,
> > Takashi Iwai wrote:
> >>
> >> On Wed, 20 Apr 2016 09:56:04 +0200,
> >> Dmitry Vyukov wrote:
> >> >
> >> > On Sun, Apr 3, 2016 at 8:33 AM, Takashi Iwai <tiwai@...e.de> wrote:
> >> > >> >> It is not easily reproducible. I've hit several times while running
> >> > >> >> fuzzer for a week. Here is one of the logs for the record:
> >> > >> >> https://gist.githubusercontent.com/dvyukov/c84798ee55721563ecb537c4d51dc9f5/raw/f00b865a85877656f13b41917f7321730f140d35/gistfile1.txt
> >> > >> >
> >> > >> > There are a few more fixes in sound/core/timer.c since 4.5, and they
> >> > >> > possibly already cover this.
> >> > >> >
> >> > >> > Please let me know if this is still seen on the upcoming 4.6-rc2.
> >> > >>
> >> > >> Hi Takashi,
> >> > >>
> >> > >> I've updated fuzzer to 05cf8077e54b20dddb756eaa26f3aeb5c38dd3cf (Apr
> >> > >> 1) yesterday. Let's see if it still happens.
> >> > >>
> >> > >> Out of curiosity, how was the bug found?
> >> > >
> >> > > Well, I'm not entirely sure whether they really cover. It's just a
> >> > > hope, as these are patches to close some possible races :)
> >> > >
> >> > > 9984d1b5835ca29fc7025186a891ee7398d21cc7
> >> > > ALSA: timer: Protect the whole snd_timer_close() with open race
> >> > > f65e0d299807d8a11812845c972493c3f9a18e10
> >> > > ALSA: timer: Call notifier in the same spinlock
> >> > > 4a07083ed613644c96c34a7dd2853dc5d7c70902
> >> > > ALSA: timer: Use mod_timer() for rearming the system timer
> >> >
> >> >
> >> > Hi Takashi,
> >> >
> >> > I've hit it again on 806fdcce017dc98c4dbf8ed001750a0d7d2bb0af (Apr
> >> > 14), all 3 commits are already in my tree.
> >> >
> >> > [ 343.222218] ------------[ cut here ]------------
> >> > [ 343.222218] WARNING: CPU: 3 PID: 7040 at kernel/time/hrtimer.c:837
> >> > hrtimer_forward+0x26a/0x3e0
> >>
> >> This is a different warning. The previous was use-after-free, and
> >> this is a warning about re-arming the queued hrtimer.
> >> Maybe there is a slightly remaining race about hrtimer_start() and the
> >> interrupt handler in snd-hrtimer.
> >
> > Could you check whether two patches below help anything?
> > This should harden against the race between hrtimer callback and
> > another start/stop calls.
>
> I don't have a reliable way to reproduce it. I've tried to replay the
> logs for hours, but no success. And I've hit it only three times:
>
> -rw-r----- 1 346004 Apr 19 02:36 crash-qemu-23-1461026201572599961
> -rw-r----- 1 393438 Mar 27 08:24 crash-qemu-8-1459059850150353721
> -rw-r----- 1 393439 Mar 10 19:44 crash-qemu-16-1457635446972474955
>
> I will merge the patches and restart the fuzzer. It will be difficult
> to conclude whether it fixes the bug or not, but at least it will test
> the patches.
Thanks! I'll test the patches for a while and merge for 4.7 if no
regression is found, too.
Takashi
Powered by blists - more mailing lists