Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 2 Feb 2020 13:22:11 +0100
From: Solar Designer <>
Cc: Al Viro <>,
	Salvatore Mesoraca <>,
	Kees Cook <>,
	Linus Torvalds <>,
	Dan Carpenter <>,
	Andrew Morton <>
Subject: Re: Linux kernel: user-triggerable read-after-free crash or 1-bit infoleak oracle in open(2)

On Wed, Jan 29, 2020 at 12:50:22AM +0100, Solar Designer wrote:
> On Tue, Jan 28, 2020 at 10:48:10PM +0100, Solar Designer wrote:
> > I intend to request a CVE ID and post it as a follow-up to this thread.
> "Use CVE-2020-8428."
> > Al Viro found and analyzed the security impact of and fixed a bug in
> > Linux 4.19+ where open(2)'s eventual call to may_create_in_sticky() was
> > "done when we already have dropped the reference to dir" and thus with
> > dir (a "struct dentry" pointer) being potentially stale and potentially
> > pointing to reused memory.
> > The bug was introduced with commit 30aba6656f61 and first included in
> > Linux 4.19.  Al fixed it with commit d0cb50185ae9 two days ago, and the
> > fix is already in Linux 5.5 and Greg KH is getting it into stable.

Turns out the fix in d0cb50185ae9 introduced a regression, now found
with syzkaller and fixed:

If I understand correctly (but I'm not confident!), this time it's just
a crash.  I am not going to request another CVE ID because the security
impact is unclear to me (perhaps an Oops with some resources held?)

My sentiment this time:

While embarrassing, it's good to know that this sort of bug (unlike the
previous one) is promptly detected by a fuzzer, and thus has a short
lifetime.  While ideally there would be no bugs in the first place,
realistically I wish more bugs would be discovered and fixed so quickly.

The kernel uses many complicated conventions these days (for performance
reasons), up to the point where it's difficult even for the most active
upstream developers to make bug-free changes and to review proposed
changes.  A lot of context needs to be considered and a lot of potential
pitfalls kept in mind.

Thanks to @grsecurity for at-mentioning me on the tweet pointing to the
above commit.  I was otherwise out of the loop this time.  That's fine,
but since I did bring the previous set of issues in here, I felt I also
needed to post this follow-up.


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.