grsecurity forums

Hello!

I'm running Arch Linux and I have compiled a custom kernel with the latest grsecurity patch (for linux-4.2.3). Everything works fine except that I'm unable to run a virtual machine using VirtualBox 5.0.6. As soon as I try to start the VM, the system hangs completely. In the kernel configuration I have selected the CONFIG_GRKERNSEC_CONFIG_VIRT_HOST and CONFIG_GRKERNSEC_CONFIG_VIRT_VIRTUALBOX options. I also compiled VirtualBox modules with dkms.

This is what I find in the journal:

Code: Select all

Oct 10 23:23:08 fux-laptop kernel: SUPR0GipMap: fGetGipCpu=0x3
Oct 10 23:23:13 fux-laptop kernel: vboxdrv: ffffffffc0822020 VMMR0.r0
Oct 10 23:23:15 fux-laptop kernel: vboxdrv: ffffffffc09c0020 VBoxDDR0.r0
Oct 10 23:23:15 fux-laptop kernel: vboxdrv: ffffffffc09df020 VBoxDD2R0.r0
Oct 10 23:23:15 fux-laptop kernel: vboxdrv: ffffffffc09e3020 VBoxEhciR0.r0
Oct 10 23:23:16 fux-laptop kernel: PAX: please report this to pageexec@freemail.hu
Oct 10 23:23:16 fux-laptop kernel: BUG: unable to handle kernel paging request at 000003c420f87560
Oct 10 23:23:16 fux-laptop kernel: IP: [<ffffffffc084785e>] 0xffffffffc084785e
Oct 10 23:23:16 fux-laptop kernel: PGD 92a14000
Oct 10 23:23:16 fux-laptop kernel: Oops: 0000 [#1] SMP
Oct 10 23:23:16 fux-laptop kernel: Modules linked in: pci_stub vboxpci(O) vboxnetflt(O) vboxnetadp(O) vboxdrv(O) ctr ccm msr ipt_REJECT nf_reject    _ipv
Oct 10 23:23:16 fux-laptop kernel:  gf128mul algif_skcipher af_alg dm_crypt dm_mod sd_mod atkbd libps2 ahci libahci ohci_pci libata ehci_pci ohci    _hcd
Oct 10 23:23:16 fux-laptop kernel: CPU: 0 PID: 24389 Comm: EMT-0 Tainted: G           O    4.2.3-grsec-cm #1
Oct 10 23:23:16 fux-laptop kernel: Hardware name: Acer AO722/JE10-BZ, BIOS V1.08 12/06/2011
Oct 10 23:23:16 fux-laptop kernel: task: ffff88003624b840 ti: ffff88003624b858 task.ti: ffff88003624b858
Oct 10 23:23:16 fux-laptop kernel: RIP: 0010:[<ffffffffc084785e>]  [<ffffffffc084785e>] 0xffffffffc084785e
Oct 10 23:23:16 fux-laptop kernel: RSP: 0018:ffffc90003503b48  EFLAGS: 00010206
Oct 10 23:23:16 fux-laptop kernel: RAX: 000003c420f87560 RBX: ffffc900035b9000 RCX: ffffc90003503b67
Oct 10 23:23:16 fux-laptop kernel: RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012
Oct 10 23:23:16 fux-laptop kernel: RBP: ffffc90003503b48 R08: 0000000000000000 R09: 0000000000000025
Oct 10 23:23:16 fux-laptop kernel: R10: 000003c420f87320 R11: 0000000000000025 R12: 000000000000000e
Oct 10 23:23:16 fux-laptop kernel: R13: 0000000000000000 R14: 00000000beef0000 R15: beef00000001927d
Oct 10 23:23:16 fux-laptop kernel: FS:  000003c440fc4700(0000) GS:ffff88010ec00000(0000) knlGS:0000000000000000
Oct 10 23:23:16 fux-laptop kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 10 23:23:16 fux-laptop kernel: CR2: 000003c420f87560 CR3: 0000000038579000 CR4: 00000000000006f0
Oct 10 23:23:16 fux-laptop kernel: Stack:
Oct 10 23:23:16 fux-laptop kernel:  ffffc90003503b78 ffffffffc082267a ffff880092944858 ffffc900035b9000
Oct 10 23:23:16 fux-laptop kernel:  000000000000000e ffffc900035b9000 ffffc90003503bd8 ffffffffc0845605
Oct 10 23:23:16 fux-laptop kernel:  00000000ffff4111 ffff8800928ba030 ffffffffffff4111 ffffffffffff4111
Oct 10 23:23:16 fux-laptop kernel: Call Trace:
Oct 10 23:23:16 fux-laptop kernel:  [<ffffffffc07c1035>] ? supdrvIOCtl+0xdb4/0x2ce6 [vboxdrv]
Oct 10 23:23:16 fux-laptop kernel:  [<ffffffffc07bc608>] ? VBoxDrvLinuxIOCtl_5_0_6+0x171/0x204 [vboxdrv]
Oct 10 23:23:16 fux-laptop kernel:  [<ffffffffb81f03eb>] ? vfs_ioctl+0x46/0x5a
Oct 10 23:23:16 fux-laptop kernel:  [<ffffffffb81f0f96>] ? do_vfs_ioctl+0x486/0x7ca
Oct 10 23:23:16 fux-laptop kernel:  [<ffffffffc0305687>] ? soundcore_open+0xae/0x1ca [soundcore]
Oct 10 23:23:16 fux-laptop kernel:  [<ffffffffb81f1337>] ? SyS_ioctl+0x5d/0x88
Oct 10 23:23:16 fux-laptop kernel:  [<ffffffffb8569f29>] ? entry_SYSCALL_64_fastpath+0x12/0x83
Oct 10 23:23:16 fux-laptop kernel: Code: 00 4c 8b 97 f8 03 00 00 45 89 d9 45 31 c0 0f 1f 80 00 00 00 00 44 89 cf 44 29 c7 d1 ef 42 8d 04 07 48 89     c7
Oct 10 23:23:16 fux-laptop kernel: RIP  [<ffffffffc084785e>] 0xffffffffc084785e
Oct 10 23:23:17 fux-laptop kernel:  RSP <ffffc90003503b48>
Oct 10 23:23:17 fux-laptop kernel: CR2: 000003c420f87560
Oct 10 23:23:17 fux-laptop kernel: ---[ end trace f6badec44ba62dd9 ]---
Oct 10 23:23:17 fux-laptop kernel: grsec: banning user with uid 1000 until system restart for suspicious kernel crash

Thanks for any help.

Just to see if this is really an incompatibility with UDEREF, could you try booting a kernel with RANDSTRUCT disabled? We had to exempt one of its structures from randomization earlier, just curious if they added a new one that needs exemption.

Thanks,
-Brad

Sure, I'll try it as soon as I can and then I'll let you know.

VirtualBox has never been and probably won't be compatible with UDEREF in the near future. It's actually a "feature" of the vboxdrv.ko module to be incompatible with UDEREF (and SMAP for that matter).

It's KERNEXEC that works for some time now. Only on x86-64, though.

spender wrote:Just to see if this is really an incompatibility with UDEREF, could you try booting a kernel with RANDSTRUCT disabled?

Ok, I tried that but nothing has changed, the system still freezes when I start the VM. I should note that this is not related specifically to the patch for linux-4.2.3, but it was the same also in the previous version.

I have also another (unrelated) issue only with this latest patch (the patch for version 4.1.7 of the kernel worked fine): if I plug into my computer a USB device, as soon as I unplug it the system freezes completely. After rebooting there is nothing in the system log that can help understand what the problem is. Since this is quite critical, for now I've downgraded the kernel to the previous version.

I'm not sure if I should create a new thread about this other problem.

Thanks, the next version of the patches will disable UDEREF when a VirtualBox host config is selected.

As for the USB issue, is there any way you could obtain serial console output? I saw https://bugs.archlinux.org/task/46673 as well but was unable to reproduce the issue in a VM. Since size_overflow can't be the culprit, I'm not sure what the issue could be. The majority of our changes to drivers/usb have to do with REFCOUNT. My quick recommendation would be to try a vanilla kernel and then the PaX patch only: https://grsecurity.net/~paxguy1/pax-lin ... est9.patch so we can track down the source of the problem in the event we aren't able to get anyone to submit serial console output.

As a follow up to this, if anyone affected by this bug tries the above and the PaX and vanilla kernels both work, could you try with KSTACKOVERFLOW disabled?

Thanks,
-Brad

you could also try to trigger the USB related freeze/crash while not under X but a normal console (and increased loglevel), that may give the kernel a chance to print out something on the screen. another option is using pstore if it's an UEFI system to store kernel logs and retrieve them on the next boot.

PaX Team wrote:you could also try to trigger the USB related freeze/crash while not under X but a normal console (and increased loglevel), that may give the kernel a chance to print out something on the screen.

Ok, this kinda worked, meaning that the kernel prints something on the screen. But since the error messages are nowhere to be found in the logs after rebooting, I don't know how to copy them here. :/

Now I'm gonna try the vanilla kernel with only the PaX patch and see what happens.

Fuxino wrote:Ok, this kinda worked, meaning that the kernel prints something on the screen. But since the error messages are nowhere to be found in the logs after rebooting, I don't know how to copy them here. :/

in such panics nothing will make it to the filesystem but you can always take a literal screenshot and post it here or email it to us (if you can run the display in a higher resolution frame buffer mode, all the better). as for pstore, here's an older LWN article about it: https://lwn.net/Articles/434821/

I'm not sure if that helps, though.

can you turn off CONFIG_BLK_DEV_THROTTLING and see if anything changes? (it won't be a fix, just narrow down the problem perhaps) also can you try a vanilla kernel alone?

Good news, this appears to be an upstream bug, likely made more reproducible by SANITIZE. Here's an upstream report showing an oops on the exact same instruction as your case: https://lkml.org/lkml/2015/9/4/155 and the fix to be included in the next test patch is here: https://lkml.org/lkml/2015/9/5/205

-Brad

spender wrote:Good news, this appears to be an upstream bug, likely made more reproducible by SANITIZE. Here's an upstream report showing an oops on the exact same instruction as your case: https://lkml.org/lkml/2015/9/4/155 and the fix to be included in the next test patch is here: https://lkml.org/lkml/2015/9/5/205

-Brad

Nice, thanks a lot. That fixed it indeed.

Back to the VirtualBox problem, I tried disabling the UDEREF option: I'm still unable to run the VM, but at least the system doesn't freeze, I just get an error message telling me that "a critical error has occurred while running the virtual machine and the machine execution has been stopped".

EDIT
Here's the VBox.log: https://gist.github.com/ab83ec8dea4409306150