On Wed, May 25, 2016 at 2:30 AM, Jeff Chua <[email protected]> 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
