Re: fs: NULL deref in atime_needs_update

[Dmitry Vyukov]

On Sat, Feb 27, 2016 at 11:27 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Feb 26, 2016 at 10:07:59PM +0000, Al Viro wrote:
>> On Fri, Feb 26, 2016 at 10:25:21PM +0100, Dmitry Vyukov wrote:
>> > On Fri, Feb 26, 2016 at 10:21 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>> > > On Thu, Feb 25, 2016 at 04:39:27PM +0000, Al Viro wrote:
>> > >> Hrm...  OK, seeing that you still seem to trigger those within an hour or
>> > >> two (and *any* of remaining WARN_ON() are serious bugs - none of the
>> > >> "mitigation had been triggered" remained, sorry for not making it clear),
>> > >> let's try this.  Again, any WARN_ON triggered means that we'd caught something,
>> > >> whether it progresses into oops or not.
>> > >
>> > > Any news on that one?  I'm going to carve fixes for understood bugs out of
>> > > that one and put those into tonight push, but it would be nice to sort out
>> > > all remaining crap lurking in that area...
>> > >
>> > > Another question: what about the very first trace you'd posted, with apparent
>> > > GPF at 00000050?  Have you seen anything like that afterwards?
>> >
>> > No, I did not have time to retest.
>> >
>> > GPF at 00000050 was not mine, it was MickaÃl's.
>>
>> Ah, OK - his is basically a forced nd->stack[] underrun, with passing a
>> never-assigned nd->link_inode to atime_needs_update(), so we are just
>> passing a contents of uninitialized stack word there and while it ends
>> up possible to dereference, it's not an address of struct inode and the
>> first attempt to follow a pointer in what would've been a struct inode
>> at that address (accessing inode->i_sb->s_flags) did blow up with GPF at
>> offsetof(struct super_block, s_flags).
>>
>> All right, so we basically have several understood ones with fixes plus
>> something unknown that leads to lookup_fast() returning 0 with NULL in
>> *inode in about an hour or two on your setup...
>
> BTW, what kind of userland are you using?  The thing is, shared-subtree
> setups differ, and if the crap is anywhere near vfsmount handling, that
> could have some impact...  So far I hadn't been able to trigger any of
> these WARN_ON(); setup here is debian/testing on 4-way KVM guest with 4Gb
> memory given to it running on a 6-way host (Phenom II X6 1100T, 3.3GHz, 16Gb
> RAM total); 4.2 with debian/stable userland on host.  What's the setup on
> your reproducer?


Restarted fuzzer with the latest patch on top of
0fcbf996d848d03573113d83f4e3fb3bcfa5ab5e.

> All that stops these warnings from triggering atime_... oopsen is that dentry
> involved isn't a symlink one.

What worries me is that I am running the same program in the same
setup. The program does operate on symlinks and previous it triggered
oopses. But now it does not. I've also rebased onto latest Linus tree,
maybe that made difference...

My userspace is a Debian Wheezy built using this script:
https://github.com/google/syzkaller/blob/master/tools/create-image.sh

I run it in qemu as:
$ qemu-system-x86_64 -hda wheezy.img -net
user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net nic -nographic -kernel
arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda debug
earlyprintk=serial slub_debug=UZ" -enable-kvm -pidfile vm_pid -m 2G
-numa node,nodeid=0,cpus=0-1 -numa node,nodeid=1,cpus=2-3 -smp
sockets=2,cores=2,threads=1 -usb -usbdevice mouse -usbdevice tablet
-soundhw all

I also use a pretty beefy config (attached) which includes KASAN and
KCOV both of which introduce significant slowdown and can affect
thread interleavings.

Attachment: .config
Description: Binary data