Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 24 Jul 2018 14:54:21 +0900
From:   DaeRyong Jeong <threeearcat@gmail.com>
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        byoungyoung@purdue.edu, kt0755@gmail.com, bammanag@purdue.edu
Message-ID: <f5266b91-0305-4d1c-af17-d982edc50035@Spark>
In-Reply-To: <20180724052929.GI30522@ZenIV.linux.org.uk>
References: <20180724034542.GA19283@dragonet>
 <20180724051726.GH30522@ZenIV.linux.org.uk>
 <20180724052929.GI30522@ZenIV.linux.org.uk>
Subject: Re: KASAN: use-after-free Read in link_path_walk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5b56bf6d_1befd79f_5b9"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--5b56bf6d_1befd79f_5b9
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Because our fuzzer has a problem, I don't have a C reproducer so far.
I reported the crash becasue I saw the crash repeatedly in our fuzzer and I hoped the report is helpful. But it seems not enough.
If I was wrong and I made you confused, I am really sorry for that.
Could you give me a second?
I am trying to fix our fuzzer and to make a C reproducer.
I think the C reproducer is necessary here.
On 24 Jul 2018, 2:29 PM +0900, Al Viro <viro@zeniv.linux.org.uk>, wrote:
> On Tue, Jul 24, 2018 at 06:17:26AM +0100, Al Viro wrote:
> > On Tue, Jul 24, 2018 at 12:45:42PM +0900, Dae R. Jeong wrote:
> > > Diagnosis:
> > > We think that it is possible that link_path_walk() dereferences a
> > > freed pointer when cleanup_mnt() is executed between path_init() and
> > > link_path_walk().
> > >
> > > Since I'm not an expert on a file system and don't fully understand
> > > the crash, please see a executed program and a crash log below in
> > > case that my understanding is wrong.
> > >
> > >
> > > Executed Program:
> > > Thread0 Thread1
> > > mkdir("./file0")
> > > |--------------------------|
> > > | mount("./file0", "./file0", "devpts", 0x0, "")
> > > | |
> > > openat(AT_FDCWD, chroot("./file0")
> > > "/dev/vcs", 0x200, 0x0) umount("./file0", 0x2)
> > >
> > > openat(), chroot(), umount() syscalls are executed after mount() syscall.
> > > We think a race occurs between openat() and chroot() because RaceFuzzer
> > > executed openat() and chroot() concurrently.
> > >
> > >
> > > (Possible) Thread interleaving:
> > > CPU0 (path_openat) CPU1 (cleanup_mnt)
>
> Wait a bloody minute. Where does cleanup_mnt() come from in that thing?
> You are doing lazy-umount of the thing you've chrooted into; if it ends
> up with zero refcount on that mount, we are already in deep, deep trouble,
> races with open() on not. Simply following that with stat / (in thread 1,
> without thread0 at all) would end up accessing the same vfsmount. And
> if it's been freed, we are well and truly fucked, race or no race.
>
> I really want details. *Is* cleanup_mnt() called by thread 1 in your
> reproducer before the use-after-free hits? And what's the root of
> thread 0 at that point?

--5b56bf6d_1befd79f_5b9
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html xmlns=3D=22http://www.w3.org/1999/xhtml=22>
<head>
<title></title>
</head>
<body>
<div name=3D=22messageBodySection=22>Because our fuzzer has a problem, I =
don't have a C reproducer so far.<br />
I reported the crash becasue I saw the crash repeatedly in our fuzzer and=
 I hoped the report is helpful. But it seems not enough.<br />
If I was wrong and I made you confused, I am really sorry for that.<br />=

Could you give me a second=3F<br />
I am trying to fix our fuzzer and to make a C reproducer.<br />
I think the C reproducer is necessary here.</div>
<div name=3D=22messageReplySection=22>On 24 Jul 2018, 2:29 PM +0900, Al V=
iro &lt;viro=40zeniv.linux.org.uk&gt;, wrote:<br />
<blockquote type=3D=22cite=22>On Tue, Jul 24, 2018 at 06:17:26AM +0100, A=
l Viro wrote:<br />
<blockquote type=3D=22cite=22>On Tue, Jul 24, 2018 at 12:45:42PM +0900, D=
ae R. Jeong wrote:<br />
<blockquote type=3D=22cite=22>Diagnosis:<br />
We think that it is possible that link=5Fpath=5Fwalk() dereferences a<br =
/>
freed pointer when cleanup=5Fmnt() is executed between path=5Finit() and<=
br />
link=5Fpath=5Fwalk().<br />
<br />
Since I'm not an expert on a file system and don't fully understand<br />=

the crash, please see a executed program and a crash log below in<br />
case that my understanding is wrong.<br />
<br />
<br />
Executed Program:<br />
Thread0 Thread1<br />
mkdir(=22./file0=22)<br />
=7C--------------------------=7C<br />
=7C mount(=22./file0=22, =22./file0=22, =22devpts=22, 0x0, =22=22)<br />
=7C =7C<br />
openat(AT=5F=46DCWD, chroot(=22./file0=22)<br />
=22/dev/vcs=22, 0x200, 0x0) umount(=22./file0=22, 0x2)<br />
<br />
openat(), chroot(), umount() syscalls are executed after mount() syscall.=
<br />
We think a race occurs between openat() and chroot() because Race=46uzzer=
<br />
executed openat() and chroot() concurrently.<br />
<br />
<br />
(Possible) Thread interleaving:<br />
CPU0 (path=5Fopenat) CPU1 (cleanup=5Fmnt)<br /></blockquote>
</blockquote>
<br />
Wait a bloody minute. Where does cleanup=5Fmnt() come from in that thing=3F=
<br />
You are doing lazy-umount of the thing you've chrooted into; if it ends<b=
r />
up with zero refcount on that mount, we are already in deep, deep trouble=
,<br />
races with open() on not. Simply following that with stat / (in thread 1,=
<br />
without thread0 at all) would end up accessing the same vfsmount. And<br =
/>
if it's been freed, we are well and truly fucked, race or no race.<br />
<br />
I really want details. *Is* cleanup=5Fmnt() called by thread 1 in your<br=
 />
reproducer before the use-after-free hits=3F And what's the root of<br />=

thread 0 at that point=3F<br /></blockquote>
</div>
</body>
</html>

--5b56bf6d_1befd79f_5b9--