linux-kernel - Re: general protection fault (btrfs_real

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: <20160518123213.GA311@x4>
Date:	Wed, 18 May 2016 14:32:13 +0200
From:	Markus Trippelsdorf <markus@...ppelsdorf.de>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	linux-kernel@...r.kernel.org, Chris Mason <clm@...com>
Subject: Re: general protection fault (btrfs_real_readdir)

On 2016.05.18 at 13:21 +0100, Al Viro wrote:
> On Wed, May 18, 2016 at 01:31:40PM +0200, Markus Trippelsdorf wrote:
> > I'm running the latest Linus git tree and the parallel filesystem directory
> > handling update seems to cause the following issue:
>  
> >  Call Trace:
> >   [<ffffffff812f038b>] ? btrfs_real_readdir+0x44b/0x540
> >   [<ffffffff811b064d>] ? SyS_getdents+0x12d/0x2a0
> >   [<ffffffff811affa0>] ? SyS_ioctl+0x6a0/0x6a0
> >   [<ffffffff810923db>] ? entry_SYSCALL_64_fastpath+0x13/0x8f
> >  Code: 02 00 00 00 00 ad de eb 1e f0 ff 4b 60 74 73 49 8b 47 40 49 8d 57 40 4c 89 fb 48 39 d5 4c 8d 78 c0 0f 84 8d 00 00 00 48 8b 53 48 <48> 89 50 08 48 89 02 4c 89 6b 40 4c 89 63 48 48 8b 4b 21 49 3b 
> >  RIP  [<ffffffff8134e9f3>] btrfs_readdir_delayed_dir_index+0x73/0x120
> >   RSP <ffff8801076e3dc0>
> >  ---[ end trace 91067801e8a68a7e ]---
> > 
> > This happened while I was building gcc, so the system was very busy.
> 
> From a very superficial reading of delayed-inode.c, it looks like delayed
> node might need locking...  This
>         list_for_each_entry_safe(curr, next, ins_list, readdir_list) {
>                 list_del(&curr->readdir_list);
> looks particularly unpleasant.  Just to make sure that this *is* just a
> readdir issue (and not something involving lookups), could you try to
> reproduce the breakage with 972b241f8 reverted?

Will give it a try later.

Just in case it may help:

(gdb) list *(btrfs_readdir_delayed_dir_index+0x73)
0xffffffff8134e9f3 is in btrfs_readdir_delayed_dir_index (include/linux/list.h:89).
84       * This is only for internal list manipulation where we know
85       * the prev/next entries already!
86       */
87      static inline void __list_del(struct list_head * prev, struct list_head * next)
88      {
89              next->prev = prev;
90              WRITE_ONCE(prev->next, next);
91      }
92
93      /**
(gdb) list *(btrfs_real_readdir+0x44b)
0xffffffff812f038b is in btrfs_real_readdir (fs/btrfs/inode.c:5858).
5853
5854            if (key_type == BTRFS_DIR_INDEX_KEY) {
5855                    if (is_curr)
5856                            ctx->pos++;
5857                    ret = btrfs_readdir_delayed_dir_index(ctx, &ins_list, &emitted);
5858                    if (ret)
5859                            goto nopos;
5860            }
5861
5862            /*

-- 
Markus