Re: fs: NULL deref in atime_needs_update

[Dmitry Vyukov]

On Sun, Feb 28, 2016 at 4:43 PM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
> 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.


What was triggered so far is this. As far as I see it it roughly the
same as before.


[ 1422.292356] ------------[ cut here ]------------
[ 1422.292841] WARNING: CPU: 0 PID: 32603 at fs/namei.c:1587
lookup_fast+0x3fa/0x450()
[ 1422.293543] Modules linked in:
[ 1422.293868] CPU: 0 PID: 32603 Comm: syz-executor Not tainted 4.5.0-rc4+ #75
[ 1422.294426] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Bochs 01/01/2011
[ 1422.294482]  0000000000000000 ffff8800148d3c48 ffffffff81931fc9
0000000000000000
[ 1422.294482]  ffffffff83314939 ffff8800148d3c80 ffffffff8116eee1
ffff8800148d3de0
[ 1422.294482]  ffff8800148d3d90 ffff8800148d3d98 ffff8800148d3d8c
0000000000000001
[ 1422.294482] Call Trace:
[ 1422.294482]  [<ffffffff81931fc9>] dump_stack+0x99/0xd0
[ 1422.294482]  [<ffffffff8116eee1>] warn_slowpath_common+0x81/0xc0
[ 1422.294482]  [<ffffffff8116efd5>] warn_slowpath_null+0x15/0x20
[ 1422.294482]  [<ffffffff8130e89a>] lookup_fast+0x3fa/0x450
[ 1422.294482]  [<ffffffff8130f388>] ? link_path_walk+0x68/0x4e0
[ 1422.294482]  [<ffffffff8130fe66>] ? path_init+0x666/0x810
[ 1422.294482]  [<ffffffff81310775>] path_openat+0x375/0x1520
[ 1422.294482]  [<ffffffff811c780d>] ? trace_hardirqs_on+0xd/0x10
[ 1422.294482]  [<ffffffff81313129>] do_filp_open+0x79/0xd0
[ 1422.294482]  [<ffffffff82ae3022>] ? _raw_spin_unlock+0x22/0x30
[ 1422.294482]  [<ffffffff81322af8>] ? __alloc_fd+0xf8/0x200
[ 1422.294482]  [<ffffffff81300c10>] do_sys_open+0x110/0x1f0
[ 1422.294482]  [<ffffffff81300d1f>] SyS_openat+0xf/0x20
[ 1422.294482]  [<ffffffff82ae3ab6>] entry_SYSCALL_64_fastpath+0x16/0x7a
[ 1422.304062] ---[ end trace 658f7fb8fc01ebf0 ]---
[ 1422.304425] ------------[ cut here ]------------
[ 1422.304842] WARNING: CPU: 0 PID: 32603 at fs/namei.c:3124
path_openat+0x12bc/0x1520()
[ 1422.305551] Modules linked in:
[ 1422.305803] CPU: 0 PID: 32603 Comm: syz-executor Tainted: G
W       4.5.0-rc4+ #75
[ 1422.306476] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Bochs 01/01/2011
[ 1422.306476]  0000000000000000 ffff8800148d3cb8 ffffffff81931fc9
0000000000000000
[ 1422.306476]  ffffffff83314939 ffff8800148d3cf0 ffffffff8116eee1
0000000000000005
[ 1422.306476]  ffff8800148d3d98 0000000000048000 ffff8800148d3de0
ffff8800148d3efc
[ 1422.306476] Call Trace:
[ 1422.306476]  [<ffffffff81931fc9>] dump_stack+0x99/0xd0
[ 1422.306476]  [<ffffffff8116eee1>] warn_slowpath_common+0x81/0xc0
[ 1422.306476]  [<ffffffff8116efd5>] warn_slowpath_null+0x15/0x20
[ 1422.306476]  [<ffffffff813116bc>] path_openat+0x12bc/0x1520
[ 1422.306476]  [<ffffffff81313129>] do_filp_open+0x79/0xd0
[ 1422.306476]  [<ffffffff82ae3022>] ? _raw_spin_unlock+0x22/0x30
[ 1422.306476]  [<ffffffff81322af8>] ? __alloc_fd+0xf8/0x200
[ 1422.306476]  [<ffffffff81300c10>] do_sys_open+0x110/0x1f0
[ 1422.306476]  [<ffffffff81300d1f>] SyS_openat+0xf/0x20
[ 1422.306476]  [<ffffffff82ae3ab6>] entry_SYSCALL_64_fastpath+0x16/0x7a
[ 1422.314201] ---[ end trace 658f7fb8fc01ebf1 ]---
INIT: Id "V0" respawning too fast: disabled for 5 minutes