linux-kernel - Re: can't boot with reiserfs on linux-4.6.0+

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: <CA+55aFxUf7=9uGtDJWNp2B2kwT8wYeLYJSj5fvGWJGmxj01tEQ@mail.gmail.com>
Date:	Wed, 25 May 2016 08:51:26 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeff Chua <jeff.chua.linux@...il.com>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: can't boot with reiserfs on linux-4.6.0+

On Wed, May 25, 2016 at 2:30 AM, Jeff Chua <jeff.chua.linux@...il.com> wrote:
>
> Here's dmesg with symbols ...

Ok, so "handler" in generic_getxattr() is NULL, the code decodes to

   0: 4d 89 c1             mov    %r8,%r9
   3: 48 8b 4c 24 08       mov    0x8(%rsp),%rcx
   8: 4d 89 e0             mov    %r12,%r8
   b: 48 89 ea             mov    %rbp,%rdx
   e: 48 89 de             mov    %rbx,%rsi
  11: 48 89 c7             mov    %rax,%rdi
  14:* ff 50 20             callq  *0x20(%rax) <-- trapping instruction
  17: 48 98                 cltq

which is

        return handler->get(handler, dentry, inode,
                            name, buffer, size);

so it's that "handler->get" access that fails ("handler" is in %rax
and %rdi, and the register state agrees).

I'm not seeing what changed for btrfs here - we had a calling
convention change, but nothing that should make handler be NULL.

I see nothing particularly odd in the call trace either:

> Call Trace:
>   get_vfs_caps_from_disk+0x51/0xcf
>   __vma_link_rb+0x58/0x73
>   cap_bprm_set_creds+0x1b0/0x420
>   prepare_binprm+0xce/0x107
>   do_execveat_common.isra.49+0x3d0/0x5b4
>   do_execve+0x1a/0x1c
>   SyS_execve+0x23/0x2a

that's the normal ->getxattr() call in security/commoncap.c, and I
don't see any changes there either apart from the calling convention.

Al, you'll probably go "Duh, I changed xyz" that I'm just missing.

               Linus