Re: Linux kernel: user-triggerable read-after-free crash or 1-bit infoleak oracle in open(2)

                							

                <!--X-Body-Begin-->
<!--X-User-Header-->

oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->

By Date

By Thread

</form>

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
Re: Linux kernel: user-triggerable read-after-free crash or 1-bit infoleak oracle in open(2)

<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->

From: Solar Designer &lt;solar () openwall com&gt;

Date: Sun, 2 Feb 2020 13:22:11 +0100

<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->

<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
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:

https://syzkaller.appspot.com/bug?extid=190005201ced78a74ad6
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6404674acd596de41fd3ad5f267b4525494a891a

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.

Alexander

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->

<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->

By Date

By Thread

Current thread:

Linux kernel: user-triggerable read-after-free crash or 1-bit infoleak oracle in open(2) Solar Designer (Jan 28)

Re: Linux kernel: user-triggerable read-after-free crash or 1-bit infoleak oracle in open(2) Solar Designer (Jan 28)

Re: Linux kernel: user-triggerable read-after-free crash or 1-bit infoleak oracle in open(2) Solar Designer (Feb 02)

Re: Linux kernel: user-triggerable read-after-free crash or 1-bit infoleak oracle in open(2) Al Viro (Feb 02)

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->