linux-kernel - Re: fs: NULL deref in atime_needs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+amZqudFFpc5R_vd+G_6i1Tq8LDNvX_2qwjoiiTFO4DxQ@mail.gmail.com>
Date:	Thu, 25 Feb 2016 09:29:21 +0100
From:	Dmitry Vyukov <dvyukov@...gle.com>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Ian Kent <raven@...maw.net>,
	Mickaël Salaün <mic@...ikod.net>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	syzkaller <syzkaller@...glegroups.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>
Subject: Re: fs: NULL deref in atime_needs_update

On Wed, Feb 24, 2016 at 4:15 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Wed, Feb 24, 2016 at 02:35:18PM +0100, Dmitry Vyukov wrote:
>
>> The warning is this one:
>>
>> static inline int should_follow_link(struct nameidata *nd, struct path *link,
>>                                      int follow,
>>                                      struct inode *inode, unsigned seq)
>> {
>> ....
>>         WARN_ON(!inode);                // now, _that_ should not happen.
>>         return pick_link(nd, link, inode, seq);
>> }
>
> Let's try it with less chatty should_follow_link() and better set of
> tripwires on the way to it:


Humm... I've left it running over night but no GPFs happened...
Usually they happened within two hours or so. I would think that your
patch fixes it and I did not actually apply it last time (or did not
rebuild kernel). But I saw the new warnings that the patch adds, so I
should have been rebuilt it...

What I saw is a dozen of pairs of warnings like the one below.
Is it possible the warning printing introduces enough delay to close
the inconsistency window?....


[46839.557154] ------------[ cut here ]------------
[46839.557663] WARNING: CPU: 0 PID: 10503 at fs/namei.c:1587
lookup_fast+0x2bf/0x420()
[46839.558239] Modules linked in:
[46839.558466] CPU: 0 PID: 10503 Comm: syz-executor Tainted: G
W       4.5.0-rc5+ #73
[46839.558980] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Bochs 01/01/2011
[46839.559174]  0000000000000000 ffff88002b6ebc48 ffffffff8194acd9
0000000000000000
[46839.559564]  ffffffff83344ffc ffff88002b6ebc80 ffffffff81172291
ffff88002b6ebde0
[46839.559564]  ffff8800314cc720 ffff88002b6ebd90 ffff88002b6ebd98
ffff88002b6ebd8c
[46839.560614] Call Trace:
[46839.560614]  [<ffffffff8194acd9>] dump_stack+0x99/0xd0
[46839.561294]  [<ffffffff81172291>] warn_slowpath_common+0x81/0xc0
[46839.561712]  [<ffffffff81172385>] warn_slowpath_null+0x15/0x20
[46839.561712]  [<ffffffff81314ddf>] lookup_fast+0x2bf/0x420
[46839.561712]  [<ffffffff81315568>] ? link_path_walk+0x68/0x4e0
[46839.561712]  [<ffffffff813172b5>] path_openat+0x375/0x1520
[46839.563137]  [<ffffffff81319499>] do_filp_open+0x79/0xd0
[46839.563137]  [<ffffffff82b11cf2>] ? _raw_spin_unlock+0x22/0x30
[46839.563137]  [<ffffffff81328e58>] ? __alloc_fd+0xf8/0x200
[46839.564353]  [<ffffffff81306eb0>] do_sys_open+0x110/0x1f0
[46839.564353]  [<ffffffff81306fbf>] SyS_openat+0xf/0x20
[46839.564353]  [<ffffffff82b12776>] entry_SYSCALL_64_fastpath+0x16/0x7a
[46839.565558] ---[ end trace 3c3bc0f927bf4e90 ]---
[46839.565858] ------------[ cut here ]------------
[46839.566203] WARNING: CPU: 0 PID: 10503 at fs/namei.c:3121
path_openat+0x12bc/0x1520()
[46839.566700] Modules linked in:
[46839.566914] CPU: 0 PID: 10503 Comm: syz-executor Tainted: G
W       4.5.0-rc5+ #73
[46839.567154] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Bochs 01/01/2011
[46839.567154]  0000000000000000 ffff88002b6ebcb8 ffffffff8194acd9
0000000000000000
[46839.567154]  ffffffff83344ffc ffff88002b6ebcf0 ffffffff81172291
0000000000000005
[46839.567154]  ffff88002b6ebd98 0000000000048000 ffff88002b6ebde0
ffff88002b6ebefc
[46839.567154] Call Trace:
[46839.567154]  [<ffffffff8194acd9>] dump_stack+0x99/0xd0
[46839.567154]  [<ffffffff81172291>] warn_slowpath_common+0x81/0xc0
[46839.567154]  [<ffffffff81172385>] warn_slowpath_null+0x15/0x20
[46839.567154]  [<ffffffff813181fc>] path_openat+0x12bc/0x1520
[46839.567154]  [<ffffffff81319499>] do_filp_open+0x79/0xd0
[46839.567154]  [<ffffffff82b11cf2>] ? _raw_spin_unlock+0x22/0x30
[46839.567154]  [<ffffffff81328e58>] ? __alloc_fd+0xf8/0x200
[46839.567154]  [<ffffffff81306eb0>] do_sys_open+0x110/0x1f0
[46839.567154]  [<ffffffff81306fbf>] SyS_openat+0xf/0x20
[46839.567154]  [<ffffffff82b12776>] entry_SYSCALL_64_fastpath+0x16/0x7a
[46839.573763] ---[ end trace 3c3bc0f927bf4e91 ]---