Steps to reproduce: 1) modprobe vboxdrv 2) Start the VirtualBox GUI and start a virtual machine 3) Observe the virtual machine abort almost immediately and the kernel oops with kernel tried to execute NX-protected page - exploit attempt? (uid: 1000, task: VirtualBox, pid: 5709)
Created attachment 240037 [details] kernel log
you should enable KALLSYMS and attach the affected module binary to see what data vbox tried to execute as code.
(In reply to comment #2) > you should enable KALLSYMS and attach the affected module binary to see what > data vbox tried to execute as code. I didn't understand a word you said.
(In reply to comment #3) > (In reply to comment #2) > > you should enable KALLSYMS and attach the affected module binary to see what > > data vbox tried to execute as code. > > I didn't understand a word you said. 1. CONFIG_KALLSYMS and CONFIG_KALLSYMS_ALL are kernel config options that grsec disables by default, so you'll have manually enable them (and possibly disable a grsec option first that forcibly disables them) and recompile your kernel. then you can reproduce your problem and get symbol information in the oops report (vs. raw addresses only that are not too helpful) which i'll need. 2. the other thing i'll need is one of the vbox kernel module binaries, i can't tell which one exactly until we see your new oops report containing symbol information but you can just attach all of them, they're not that big (or email them directly to me).
(In reply to comment #4) > 1. CONFIG_KALLSYMS and CONFIG_KALLSYMS_ALL are kernel config options that grsec > disables by default, so you'll have manually enable them (and possibly disable > a grsec option first that forcibly disables them) and recompile your kernel. > then you can reproduce your problem and get symbol information in the oops > report (vs. raw addresses only that are not too helpful) which i'll need. Looking at /proc/config.gz, they're already enabled (as is CONFIG_KALLSYMS_EXTRA_PASS), but I still get raw addresses. I'll try with CONFIG_DEBUG_INFO=y, maybe the frame pointers are stripped by something. Could grsec turn those off without warning?
I also switched on CONFIG_DEBUG_INFO=y but I still only get system addresses. Help?
(In reply to comment #6) > I also switched on CONFIG_DEBUG_INFO=y but I still only get system addresses. > Help? can you post these new logs? but first you should reproduce the problem under .35.7 because we no longer support .34. then if all else fails, i'll need your vmlinux image that corresponds to the oops log and the vbox modules and i'll try to manually decode the oops.
(In reply to comment #7) > can you post these new logs? but first you should reproduce the problem under > .35.7 because we no longer support .34. then if all else fails, i'll need your > vmlinux image that corresponds to the oops log and the vbox modules and i'll > try to manually decode the oops. Ok, I'll try hardened-sources-2.6.35-r5. PS: If you don't support ~hardened-sources-2.6.34, why is it still in portage and marked as stable?
Created attachment 251991 [details] hardened-sources-2.6.35-r5 messages VirtualBox related messages from dmesg.
Created attachment 251993 [details] System.map System.map for hardened-sources-2.6.35-r5
Created attachment 251995 [details] vboxdrv.ko
Created attachment 251997 [details] vboxnetadp.ko
Created attachment 251999 [details] vboxnetflt.ko
Created attachment 252001 [details] vmlinux (part 1) cp vmlinux.bz2.part1 vmlinux.bz2
Created attachment 252003 [details] vmlinux (part 2) cat vmlinux.bz2.part2 >> vmlinux.bz2
Created attachment 252005 [details] vmlinux (part 3) cat vmlinux.bz2.part3 >> vmlinux.bz2 md5sum vmlinux.bz2 # Should be cb567988be3aea81d4e5db1e981c87a4 bunzip2 vmlinux.bz2
All of these attachments are from hardened-sources-2.6.35-r5 and virtualbox-modules-3.2.10. vmlinux file was from /usr/src/linux/arch/x86/boot/compressed/vmlinux.
(In reply to comment #8) > PS: If you don't support ~hardened-sources-2.6.34, why is it still in portage > and marked as stable? the 'we' in my comment refers to spender/me only, not the gentoo folks ;). in general when people encounter grsec/PaX related issues, we prefer that they reproduce the issue with our latest patches since there's nothing more frustrating than wastin time on a problem that we may very well have fixed already (this is a very fast moving project at times).
can you try the latest .32 or .36 PaX or grsec patches? i've fixed some issues to support some methods that vbox/vmware use to allocate executable memory and while i386 cannot be fully fixed on my side, amd64 may work now.
(In reply to comment #19) > can you try the latest .32 or .36 PaX or grsec patches? i've fixed some issues > to support some methods that vbox/vmware use to allocate executable memory and > while i386 cannot be fully fixed on my side, amd64 may work now. Is the .36 patch already in hardened-sources-2.6.36-r1 or do I have to download it separately from somewhere?
(In reply to comment #20) > (In reply to comment #19) > > can you try the latest .32 or .36 PaX or grsec patches? i've fixed some issues > > to support some methods that vbox/vmware use to allocate executable memory and > > while i386 cannot be fully fixed on my side, amd64 may work now. > > Is the .36 patch already in hardened-sources-2.6.36-r1 or do I have to download > it separately from somewhere? > h-s-2.6.36-r1 is based on grsecurity-2.2.0-2.6.36-201011131640 which is too early. Pipacs: does grsecurity-2.2.0-2.6.36-201011151726 have the fix? If so I can get it into the tree as -r2.
(In reply to comment #21) > Pipacs: does grsecurity-2.2.0-2.6.36-201011151726 have the fix? If so I can > get it into the tree as -r2. yes, it should be in there.
(In reply to comment #22) > (In reply to comment #21) > > Pipacs: does grsecurity-2.2.0-2.6.36-201011151726 have the fix? If so I can > > get it into the tree as -r2. > > yes, it should be in there. > Okay, both the following should have the fix and are in the tree. Please test. hardened-sources-2.6.32-r27 based grsecurity-2.2.0-2.6.32.25-201011151726 hardened-sources-2.6.36-r2 based grsecurity-2.2.0-2.6.36-201011151726
This this time its app-emulation/virtualbox-bin and hardened-sources-2.6.36-r2: [ 1154.202460] vboxdrv: Trying to deactivate the NMI watchdog permanently... [ 1154.202464] vboxdrv: Warning: 2.6.31+ kernel detected. Most likely the hardware performance [ 1154.202465] vboxdrv: counter framework which can generate NMIs is active. You have to prevent [ 1154.202466] vboxdrv: the usage of hardware performance counters by [ 1154.202467] vboxdrv: echo 2 > /proc/sys/kernel/perf_counter_paranoid [ 1154.202468] vboxdrv: Found 2 processor cores. [ 1154.202533] VBoxDrv: dbg - g_abExecMemory=ffffffffa0122000 [ 1154.202555] vboxdrv: fAsync=0 offMin=0x199 offMax=0x6d4 [ 1154.202595] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'. [ 1154.202596] vboxdrv: Successfully loaded version 3.2.10 (interface 0x00140001). [ 1161.444147] warning: `VirtualBox' uses 32-bit capabilities (legacy support in use) [ 1161.553735] grsec: denied resource overstep by requesting 21 for RLIMIT_NICE against limit 0 for /opt/VirtualBox/VirtualBox[VirtualBox:5139] uid/euid:1000/1000 gid/egid:100/100, parent /usr/bin/kdeinit4[kdeinit4:4753] uid/euid:1000/1000 gid/egid:100/100 [ 1161.553774] grsec: denied resource overstep by requesting 20 for RLIMIT_NICE against limit 0 for /opt/VirtualBox/VirtualBox[VirtualBox:5139] uid/euid:1000/1000 gid/egid:100/100, parent /usr/bin/kdeinit4[kdeinit4:4753] uid/euid:1000/1000 gid/egid:100/100 [ 1161.553786] grsec: denied resource overstep by requesting 20 for RLIMIT_NICE against limit 0 for /opt/VirtualBox/VirtualBox[VirtualBox:5139] uid/euid:1000/1000 gid/egid:100/100, parent /usr/bin/kdeinit4[kdeinit4:4753] uid/euid:1000/1000 gid/egid:100/100 [ 1162.835472] grsec: denied resource overstep by requesting 21 for RLIMIT_NICE against limit 0 for /opt/VirtualBox/VBoxXPCOMIPCD[VBoxXPCOMIPCD:5143] uid/euid:1000/1000 gid/egid:100/100, parent /opt/VirtualBox/VirtualBox[VirtualBox:5141] uid/euid:1000/1000 gid/egid:100/100 [ 1162.835497] grsec: denied resource overstep by requesting 20 for RLIMIT_NICE against limit 0 for /opt/VirtualBox/VBoxXPCOMIPCD[VBoxXPCOMIPCD:5143] uid/euid:1000/1000 gid/egid:100/100, parent /opt/VirtualBox/VirtualBox[VirtualBox:5141] uid/euid:1000/1000 gid/egid:100/100 [ 1162.835501] grsec: more alerts, logging disabled for 10 seconds [ 1173.409422] kernel tried to execute NX-protected page - exploit attempt? (uid: 1000, task: VirtualBox, pid: 5178) [ 1173.409475] BUG: unable to handle kernel paging request at ffffffffa0134bd0 [ 1173.409507] IP: [<ffffffffa0134bd0>] g_abExecMemory+0x12bd0/0x182260 [vboxdrv] [ 1173.409555] PGD 165b067 PUD 1661063 PMD 13d1dc063 PTE 8000000117899163 [ 1173.409603] Oops: 0011 [#1] PREEMPT SMP [ 1173.409631] last sysfs file: /sys/devices/virtual/dmi/id/product_version [ 1173.409665] CPU 0 [ 1173.409676] Modules linked in: vboxnetadp vboxnetflt vboxdrv snd_seq snd_seq_device snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd snd_page_alloc psmouse [ 1173.409784] [ 1173.409795] Pid: 5178, comm: VirtualBox Not tainted 2.6.36-hardened-r2-arm #1 S118DB/ESPRIMO Mobile U9210 [ 1173.409832] RIP: 0010:[<ffffffffa0134bd0>] [<ffffffffa0134bd0>] g_abExecMemory+0x12bd0/0x182260 [vboxdrv] [ 1173.409882] RSP: 0018:ffff880111571d20 EFLAGS: 00010282 [ 1173.409911] RAX: ffffffffa0134bd0 RBX: ffffc9002458b010 RCX: ffffffffa0135a90 [ 1173.409939] RDX: 0000000000000000 RSI: ffffffffa0134cc0 RDI: ffffffffa0134cb0 [ 1173.409967] RBP: ffff880111571db8 R08: 0000160000000000 R09: ffffc9002460f000 [ 1173.409996] R10: ffff88013fc22918 R11: 8000000000000163 R12: ffffffffa02a44a0 [ 1173.410012] R13: ffff880111544b10 R14: 00000000000027f0 R15: 00000000000004fe [ 1173.410012] FS: 000003264d659710(0000) GS:ffff880001e00000(0000) knlGS:0000000000000000 [ 1173.410012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1173.410012] CR2: ffffffffa0134bd0 CR3: 0000000001656000 CR4: 00000000000406f0 [ 1173.410012] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1173.410012] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 1173.410012] Process VirtualBox (pid: 5178, threadinfo ffff880111570000, task ffff88013feb2ca0) [ 1173.410012] Stack: [ 1173.410012] ffffffffa02ad94f 000000000007455c 0000000000000000 000003264d226010 [ 1173.410012] <0> 000000000000709c 00000000000744f0 000004fe000744f0 ffffc9002458b07c [ 1173.410012] <0> ffff880117bd5810 000003264d28f27c 0000000000000000 ffff880111571d88 [ 1173.410012] Call Trace: [ 1173.410012] [<ffffffffa02ad94f>] ? supdrvIOCtl+0x11cf/0x2590 [vboxdrv] [ 1173.410012] [<ffffffff810a22e8>] ? lru_cache_add_lru+0x28/0x50 [ 1173.410012] [<ffffffffa02a9483>] SUPR0Printf+0x273/0x510 [vboxdrv] [ 1173.410012] [<ffffffff810e2f27>] do_vfs_ioctl+0xa7/0x780 [ 1173.410012] [<ffffffff810e364a>] sys_ioctl+0x4a/0x80 [ 1173.410012] [<ffffffff8100268b>] system_call_fastpath+0x16/0x1b [ 1173.410012] Code: f6 c3 cc cd f7 c3 cc cd f8 c3 cc cd f9 c3 cc cd fa c3 cc cd fb c3 cc cd fc c3 cc cd fd c3 cc cd fe c3 cc cd ff c3 cc cc cc cc 90 <55> 48 89 e5 53 48 83 ec 08 e8 62 1f ff ff 85 c0 89 c3 78 4b e8 [ 1173.410012] RIP [<ffffffffa0134bd0>] g_abExecMemory+0x12bd0/0x182260 [vboxdrv] [ 1173.410012] RSP <ffff880111571d20> [ 1173.410012] CR2: ffffffffa0134bd0 [ 1173.410012] ---[ end trace 06e57ddc174732a4 ]---
is there still a problem with the latest PaX patch? (i'll note for the record that UDEREF must be disabled for vbox to work, it's their bug)
(In reply to comment #25) > is there still a problem with the latest PaX patch? (i'll note for the record > that UDEREF must be disabled for vbox to work, it's their bug) > I just tested Virtualbox with hardened-sources-2.6.32-r32 (based on grsecurity-2.2.1-2.6.32.27-201012182005) and it works no problem. Of course UDEREF is off. I think this bug is fixed. I'm closing it for now. Please reopen if you encounter any further problems.
I think I may have prematurely closed this bug: I tested virtualbox-modules 3.1.8 and it worked. When I tested 3.2.12 I hit a panic on amd64. The original bug was about 3.2.10 which I have yet to test. There are a cluster of bugs with respect to 3.2.12 on hardened profiles. I'm going to open a tracker bug to follow all these issues. When I've tested 3.2.10 I'll re-open this bug if necessary.
(In reply to comment #27) > When I tested 3.2.12 I hit a panic on amd64. have you got any logs/vmlinux/etc to share? ;)
