Is this a real detection? I remember, to an earlier thread about the same detection, but no further information.
The last grsec patch which was working for my machines was grsecurity-3.1-4.2.6-201511182042.patch
- Code: Select all
[ 3347.316617] PAX: size overflow detected in function __vhost_add_used_n drivers/vhost/vhost.c:1517 cicus.511_199 max, count: 7, decl: last_used_idx; num: 0; context: vhost_virtqueue;
[ 3347.316633] CPU: 2 PID: 10300 Comm: vhost-10299 Tainted: G OE 4.2.6 #1
[ 3347.316634] Hardware name: ASUS All Series/Z87M-PLUS, BIOS 1107 11/04/2014
[ 3347.316636] ffff880604080078 ffffc9000cc9bbd8 ffffffff81753735 0000000000000001
[ 3347.316638] 000000000000ffff ffffc9000cc9bbe8 ffffffff8119c0a4 ffffc9000cc9bc38
[ 3347.316639] ffffffffa08b1785 ffffffff81353846 ffffffff8135ccd9 000000000000000c
[ 3347.316641] Call Trace:
[ 3347.316646] [<ffffffff81753735>] dump_stack+0x45/0x5d
[ 3347.316649] [<ffffffff8119c0a4>] report_size_overflow+0x24/0x30
[ 3347.316654] [<ffffffffa08b1785>] __vhost_add_used_n+0x1d5/0x1e0 [vhost]
[ 3347.316658] [<ffffffff81353846>] ? copy_user_enhanced_fast_string+0x16/0x20
[ 3347.316660] [<ffffffff8135ccd9>] ? copy_to_iter+0x229/0x780
[ 3347.316662] [<ffffffffa08b1d8c>] vhost_add_used_n+0x8c/0x1c0 [vhost]
[ 3347.316664] [<ffffffffa08b2d8a>] vhost_add_used_and_signal_n+0x1a/0x30 [vhost]
[ 3347.316666] [<ffffffffa08bdcab>] handle_rx+0x60b/0x8e0 [vhost_net]
[ 3347.316668] [<ffffffffa08bdf90>] handle_rx_net+0x10/0x20 [vhost_net]
[ 3347.316670] [<ffffffffa08b1530>] vhost_worker+0xe0/0x160 [vhost]
[ 3347.316672] [<ffffffffa08b1450>] ? vhost_log_write+0xa0/0xa0 [vhost]
[ 3347.316675] [<ffffffff81081030>] kthread+0xd0/0xf0
[ 3347.316677] [<ffffffff81080f60>] ? kthread_create_on_node+0x170/0x170
[ 3347.316679] [<ffffffff8175b1de>] ret_from_fork+0x3e/0x70
[ 3347.316681] [<ffffffff81080f60>] ? kthread_create_on_node+0x170/0x170
[ 3845.374079] INFO: task qemu-system-x86:10301 blocked for more than 120 seconds.
[ 3845.374087] Tainted: G OE 4.2.6 #1
[ 3845.374089] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 3845.374091] qemu-system-x86 D ffff88069fa10d00 0 10301 1 0x00000000
[ 3845.374097] ffffc9000cca3be8 0000000000000082 ffffffff820049e0 ffff880604078a80
[ 3845.374102] ffffc9000cca3bc8 ffffffff8117aaa1 ffffc9000cca3bc8 ffff8806040794c8
[ 3845.374105] ffff880604078a80 ffff880604080084 00000000ffffffff ffff880604080088
[ 3845.374109] Call Trace:
[ 3845.374116] [<ffffffff8117aaa1>] ? kfree+0x21/0xf0
[ 3845.374122] [<ffffffff817574d2>] schedule+0x32/0x80
[ 3845.374126] [<ffffffff817577a9>] schedule_preempt_disabled+0x9/0x20
[ 3845.374130] [<ffffffff81758a67>] __mutex_lock_slowpath+0x87/0xe7
[ 3845.374134] [<ffffffff8175871b>] mutex_lock+0x2b/0x45
[ 3845.374144] [<ffffffffa08b1321>] memory_access_ok.isra.17+0x71/0xd0 [vhost]
[ 3845.374150] [<ffffffffa08b2465>] vhost_dev_ioctl+0x455/0x660 [vhost]
[ 3845.374154] [<ffffffffa08be669>] vhost_net_ioctl+0x1c9/0xb00 [vhost_net]
[ 3845.374171] [<ffffffffa0590bff>] ? kvm_vm_ioctl+0x5ff/0x8e0 [kvm]
[ 3845.374177] [<ffffffff810d54bb>] ? do_futex+0x10b/0xb50
[ 3845.374181] [<ffffffff811ab398>] do_vfs_ioctl+0x498/0x830
[ 3845.374184] [<ffffffff811ab7aa>] SyS_ioctl+0x7a/0x90
[ 3845.374187] [<ffffffff8175ade4>] entry_SYSCALL_64_fastpath+0x16/0x77
When this happens, my virtual machines loose their network connectivity