Crash on load Debian 10

zrose584 commented 4 years ago

copied from here:

Oct 25 03:46:04 dev kernel: [236064.560845] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
Oct 25 03:46:04 dev kernel: [236064.560848] BUG: unable to handle kernel paging request at ffffffffc00301b0
Oct 25 03:46:04 dev kernel: [236064.560849] PGD 3280e067 P4D 3280e067 PUD 32810067 PMD 359c6067 PTE 8000000079f05063
Oct 25 03:46:04 dev kernel: [236064.560852] Oops: 0011 [#1] SMP PTI
Oct 25 03:46:04 dev kernel: [236064.560854] CPU: 0 PID: 10398 Comm: kworker/u2:2 Tainted: G           OE     4.19.0-6-amd64 #1 Debian 4.19.67-2+deb10u1
Oct 25 03:46:04 dev kernel: [236064.560854] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Oct 25 03:46:04 dev kernel: [236064.560857] Workqueue: events_unbound call_usermodehelper_exec_work

Host info:

Linux debian 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

khook_demo

milabs commented 4 years ago

Could you try https://github.com/milabs/khook/tree/dev/khook branch?

zrose584 commented 4 years ago

It seems to work. However, while khook-demo.ko is loaded, it spams

...
[25385.551901] khook_inode_permission(00000000a6d102aa, 00000081) = 0
[25385.551902] khook_inode_permission(00000000e7f5063e, 00000081) = 0
[25385.551907] khook_inode_permission(000000000978fe32, 00000024) = 0
[25385.551907] khook_inode_permission(000000004458c1c4, 00000081) = 0
...

and this results in 100% CPU usage, even when not actively viewing kernlog in term. Using dmesg | cut -c 39-54 | sort | uniq, it seems like these are always the same 24-35 or so inodes. Is this normal? What could be the cause of this?

edit: after looking up the inode->i_ino, these are some of the files

//var
/var/log
/usr/share/locale/kv/LC_MESSAGES
/lib/modules/4.19.0-6-amd64
/usr/share/locale/sc/LC_MESSAGES/iso_4217.mo
/usr/src/linux-headers-4.19.0-6-common/arch/mips/include/asm/mach-vr41xx/irq.h
//lib
/lib/x86_64-linux-gnu
/lib/modules
/lib/x86_64-linux-gnu/libc-2.28.so
/lib/x86_64-linux-gnu/libdl-2.28.so
/lib/x86_64-linux-gnu/libpthread-2.28.so
/lib/modules/4.19.0-6-amd64/modules.softdep
/lib/modules/4.19.0-6-amd64/modules.builtin.bin

/run/systemd/journal/flushed
/sys/kernel/debug/bdi
/
/sys/fs
/sys/fs/cgroup/rdma/cgroup.procs
/sys/fs/cgroup/cpu,cpuacct/cgroup.procs

milabs commented 4 years ago

and this results in 100% CPU usage

Could you comment-out printk in demo and see how the CPU usage will change?

zrose584 commented 4 years ago

It is normal then. So printk indirectly uses inode_permission?

milabs commented 4 years ago

printk writes to the kernel log which causes the journald to fetch the data from the kernel log and save it to the file. The last operation triggers inode_permission (which is hooked) so the printk called again and so on

milabs commented 4 years ago

Solved via 79956e3fb60c66e9f7e6cddd2ebbf135ca5489fd

milabs / khook

Crash on load Debian 10 #7