Re: [Jfs-discussion] [PATCH] jfs: Expand usercopy whitelist for inline inode data

Re: [Jfs-discussion] [PATCH] jfs: Expand usercopy whitelist for inline inode data

[Christian Kujau]

On Fri, 3 Aug 2018, Kees Cook via Jfs-discussion wrote:
> Bart Massey reported what turned out to be a usercopy whitelist false
> positive in JFS when symlink contents exceeded 128 bytes. The inline
> inode data (i_inline) is actually designed to overflow into the "extended

So, this may be a stupid question, but: is there a way to disable this 
hardened usercopy thing with a boot option maybe?

Apparently, CONFIG_HARDENED_USERCOPY_FALLBACK was disabled in Debian's 
4.16.0-0.bpo.2-amd64 (4.16.16) kernels[0] and I have a VMware guest here 
that prints a BUG message (below) whenever a certain directory is being 
accesses. ls(1) is fine, but "ls -l" (i.e. with stat()) produces the splat 
below. And indeed, the target of one of the symlinks inside is 129 
characters long, and every attempt to stat it prints the splat below.

Going back to 4.16.0-0.bpo.1-amd64 (4.16.5) helps, but I was wondering if 
there was a magic boot option to disable it while I wait for 4.18 to land 
in Debian? I booted with hardened_usercopy=off, but it doesn't seem to 
have an effect and the directory is still inaccessible.

Thanks,
Christian.

[0] https://salsa.debian.org/kernel-team/linux/tree/stretch-backports/debian/config/


---[ end trace dbb1a6dfa1411526 ]---
usercopy: Kernel memory exposure attempt detected from SLUB object 
'jfs_ip' (offset 288, size 129)!
------------[ cut here ]------------
kernel BUG at /build/linux-hvYKKE/linux-4.17.8/mm/usercopy.c:100!
invalid opcode: 0000 [#2] SMP PTI
Modules linked in: xt_tcpudp iptable_filter binfmt_misc zram zsmalloc 
vmw_vsock_vmci_transport vsock ip_tables x_tables xts twofish_x86_64_3way 
twofish_x86_64 twofish_common lrw jfs glue_helper gf128mul dm_crypt dm_mod 
sd_mod evdev vmxnet3 mptsas scsi_transport_sas mptscsih mptbase vmw_vmci 
ata_piix libata scsi_mod button
CPU: 0 PID: 1349 Comm: ls Tainted: G      D           4.17.0-0.bpo.1-amd64 
#1 Debian 4.17.8-1~bpo9+1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop 
Reference Platform, BIOS 6.00 09/21/2015
RIP: 0010:usercopy_abort+0x69/0x80
RSP: 0018:ffffb84e40e2fe18 EFLAGS: 00010286
RAX: 0000000000000063 RBX: 0000000000000081 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff9786ffc16738 RDI: ffff9786ffc16738
RBP: 0000000000000081 R08: 0000000000000000 R09: 000000000000042e
R10: ffffffff9c68af71 R11: 323120657a697320 R12: 0000000000000001
R13: ffff9786f93146a1 R14: 0000000000000082 R15: 0000559dd2edb170
FS:  00007fe8f13733c0(0000) GS:ffff9786ffc00000(0000) 
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000559dd2edb088 CR3: 000000003d104002 CR4: 00000000003606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 __check_heap_object+0xeb/0x120
 __check_object_size+0xb8/0x1a0
 readlink_copy+0x3e/0x60
 vfs_readlink+0x60/0x120
 do_readlinkat+0xf9/0x120
 __x64_sys_readlink+0x1b/0x20
 do_syscall_64+0x55/0x110
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fe8f0c6fe47
RSP: 002b:00007ffe94d04528 EFLAGS: 00000202 ORIG_RAX: 0000000000000059
RAX: ffffffffffffffda RBX: 0000000000000082 RCX: 00007fe8f0c6fe47
RDX: 0000000000000082 RSI: 0000559dd2edb170 RDI: 00007ffe94d04570
RBP: 0000559dd2edb170 R08: 0000000000000003 R09: 0000000000000090
R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffe94d04570
R13: 00007ffe94d04570 R14: 3fffffffffffffff R15: 7ffffffffffffffe
Code: 0f 44 d0 53 48 c7 c0 58 05 65 9c 51 48 c7 c6 12 f9 63 9c 41 53 48 89 
f9 48 0f 45 f0 4c 89 d2 48 c7 c7 40 06 65 9c e8 05 97 e9 ff <0f> 0b 49 c7 
c1 03 09 66 9c 4d 89 cb 4d 89 c8 eb a5 66 0f 1f 44 
RIP: usercopy_abort+0x69/0x80 RSP: ffffb84e40e2fe18
---[ end trace dbb1a6dfa1411527 ]---


-- 
BOFH excuse #404:

Sysadmin accidentally destroyed pager with a large hammer.

Re: [Jfs-discussion] [PATCH] jfs: Expand usercopy whitelist for inline inode data

[Kees Cook]

On Thu, Aug 16, 2018 at 11:56 PM, Christian Kujau <lists@nerdbynature.de> wrote:
> On Fri, 3 Aug 2018, Kees Cook via Jfs-discussion wrote:
>> Bart Massey reported what turned out to be a usercopy whitelist false
>> positive in JFS when symlink contents exceeded 128 bytes. The inline
>> inode data (i_inline) is actually designed to overflow into the "extended
>
> So, this may be a stupid question, but: is there a way to disable this
> hardened usercopy thing with a boot option maybe?
>
> Apparently, CONFIG_HARDENED_USERCOPY_FALLBACK was disabled in Debian's
> 4.16.0-0.bpo.2-amd64 (4.16.16) kernels[0] and I have a VMware guest here
> that prints a BUG message (below) whenever a certain directory is being
> accesses. ls(1) is fine, but "ls -l" (i.e. with stat()) produces the splat
> below. And indeed, the target of one of the symlinks inside is 129
> characters long, and every attempt to stat it prints the splat below.
>
> Going back to 4.16.0-0.bpo.1-amd64 (4.16.5) helps, but I was wondering if
> there was a magic boot option to disable it while I wait for 4.18 to land
> in Debian? I booted with hardened_usercopy=off, but it doesn't seem to
> have an effect and the directory is still inaccessible.

Precisely this was just added upstream[1] for 4.19 but isn't available
in 4.16. It should be trivial to backport it, though, if Ben wants to
do that? (The JFS fix is in the 4.17 and 4.18 -stable trees now, too,
BTW.)

-Kees

[1] https://git.kernel.org/linus/b5cb15d9372a

-- 
Kees Cook
Pixel Security

Re: [Jfs-discussion] [PATCH] jfs: Expand usercopy whitelist for inline inode data

[Christian Kujau]

On Fri, 17 Aug 2018, Kees Cook wrote:
> On Thu, Aug 16, 2018 at 11:56 PM, Christian Kujau <lists@nerdbynature.de> wrote:
> > On Fri, 3 Aug 2018, Kees Cook via Jfs-discussion wrote:
> >> Bart Massey reported what turned out to be a usercopy whitelist false
> >> positive in JFS when symlink contents exceeded 128 bytes. The inline
> >> inode data (i_inline) is actually designed to overflow into the "extended
> >
> > So, this may be a stupid question, but: is there a way to disable this
> > hardened usercopy thing with a boot option maybe?
> >
> > Apparently, CONFIG_HARDENED_USERCOPY_FALLBACK was disabled in Debian's
> > 4.16.0-0.bpo.2-amd64 (4.16.16) kernels[0] and I have a VMware guest here
> > that prints a BUG message (below) whenever a certain directory is being
> > accesses. ls(1) is fine, but "ls -l" (i.e. with stat()) produces the splat
> > below. And indeed, the target of one of the symlinks inside is 129
> > characters long, and every attempt to stat it prints the splat below.
> >
> > Going back to 4.16.0-0.bpo.1-amd64 (4.16.5) helps, but I was wondering if
> > there was a magic boot option to disable it while I wait for 4.18 to land
> > in Debian? I booted with hardened_usercopy=off, but it doesn't seem to
> > have an effect and the directory is still inaccessible.
> 
> Precisely this was just added upstream[1] for 4.19 but isn't available
> in 4.16. It should be trivial to backport it, though, if Ben wants to
> do that? (The JFS fix is in the 4.17 and 4.18 -stable trees now, too,
> BTW.)

Ah, OK. While the patch does apply (almost) cleanly to 4.16, I think I'll 
just wait until it makes its way into the Debian (backports) kernel, as 
nobody else seems to be annoyed by this :-)

Thanks!
Christian.
-- 
BOFH excuse #53:

Little hamster in running wheel had coronary; waiting for replacement to be Fedexed from Wyoming