[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hwohpjxrk.wl-tiwai@suse.de>
Date: Thu, 13 Jun 2019 17:44:15 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Sasha Levin <sashal@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
syzbot+e4c8abb920efa77bace9@...kaller.appspotmail.com
Subject: Re: [PATCH 4.14 61/81] ALSA: seq: Protect in-kernel ioctl calls with mutex
On Thu, 13 Jun 2019 17:39:46 +0200,
Sasha Levin wrote:
>
> On Thu, Jun 13, 2019 at 11:13:55AM +0200, Takashi Iwai wrote:
> >On Thu, 13 Jun 2019 11:11:22 +0200,
> >Greg Kroah-Hartman wrote:
> >>
> >> On Thu, Jun 13, 2019 at 11:02:54AM +0200, Takashi Iwai wrote:
> >> > On Thu, 13 Jun 2019 10:33:44 +0200,
> >> > Greg Kroah-Hartman wrote:
> >> > >
> >> > > [ Upstream commit feb689025fbb6f0aa6297d3ddf97de945ea4ad32 ]
> >> > >
> >> > > ALSA OSS sequencer calls the ioctl function indirectly via
> >> > > snd_seq_kernel_client_ctl(). While we already applied the protection
> >> > > against races between the normal ioctls and writes via the client's
> >> > > ioctl_mutex, this code path was left untouched. And this seems to be
> >> > > the cause of still remaining some rare UAF as spontaneously triggered
> >> > > by syzkaller.
> >> > >
> >> > > For the sake of robustness, wrap the ioctl_mutex also for the call via
> >> > > snd_seq_kernel_client_ctl(), too.
> >> > >
> >> > > Reported-by: syzbot+e4c8abb920efa77bace9@...kaller.appspotmail.com
> >> > > Signed-off-by: Takashi Iwai <tiwai@...e.de>
> >> > > Signed-off-by: Sasha Levin <sashal@...nel.org>
> >> >
> >> > This commit is reverted later by commit f0654ba94e33.
> >> > So please drop this. The proper fix is done later by commit
> >> > 7c32ae35fbf9 ("ALSA: seq: Cover unsubscribe_port() in list_mutex")
> >> >
> >> > Ditto for 4.19.y and 5.1.y.
> >>
> >> Now dropped everywhere, and I added 7c32ae35fbf9 ("ALSA: seq: Cover
> >> unsubscribe_port() in list_mutex") everywhere instead.
> >
> >Thanks!
> >
> >BTW, do we have a systematic check whether the selected stable commit
> >is reverted in a later commit? At least, you can track it as long as
> >Fixes tag is properly set.
>
> I have that scripting in place, and I usually check it once before I
> send the initial reviews and then once Greg does the -rc release.
OK, good to hear. So this time must be some exceptional error.
thanks,
Takashi
Powered by blists - more mailing lists