LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Kernel (https://www.linuxquestions.org/questions/linux-kernel-70/)
-   -   How to crash kernel "on purpose" from fs/exec.c ? (https://www.linuxquestions.org/questions/linux-kernel-70/how-to-crash-kernel-on-purpose-from-fs-exec-c-4175618016/)

satanfu 11-20-2017 03:03 PM

How to crash kernel "on purpose" from fs/exec.c ?
 
Hi, folks!

I've been trying, for research/fun purpose, to crash the kernel from specific kernel functions (or to render the system unuseable) after testing a condition in fs/exec.c , lets say inside do_execveat_common().

I've tried almost everything, from a divbyzero, null dereference, infinite loop, ... Kernel displays some error, but is still alive and system runs. I'm beginning to understand that this execve* kernel code is executed after a fork of some sort, so only the executed process will die, not the kernel.

I've tried as well to call various functions (without any knowledge of them) like emergency_sync();
kernel_restart(NULL);
or ctrl_alt_del(),
but it actually doesnt compile.

My question is then, how can I f*ck up the kernel from here?

Many thanks!

sundialsvcs 11-20-2017 10:57 PM

Well, I suppose that I could mention that certain Universities actually created a crash system command in their Unix timesharing systems of yesteryear. (It proved to be the best way to persuade bored-but-brilliant young students from finding other ways to crash it: "make the process trivially easy to do, therefore no longer amusing.")

But seriously ... for very obvious reasons, the kernel is designed to protect itself against anything that any user process might (maliciously or accidentally) do.

User-land processes of course cannot call any function within the kernel code. It should come as no surprise to you that user-land code which attempts to do so will not compile.

satanfu 11-21-2017 01:33 AM

Please read me well :)
 
Quote:

Originally Posted by sundialsvcs (Post 5783226)
Well, I suppose that I could mention that certain Universities actually created a crash system command in their Unix timesharing systems of yesteryear. (It proved to be the best way to persuade bored-but-brilliant young students from finding other ways to crash it: "make the process trivially easy to do, therefore no longer amusing.")

But seriously ... for very obvious reasons, the kernel is designed to protect itself against anything that any user process might (maliciously or accidentally) do.

User-land processes of course cannot call any function within the kernel code. It should come as no surprise to you that user-land code which attempts to do so will not compile.

Hi sundialsvcs, please read me well. The code I'm patching is kernel sources (fs/exec.c). Those kernel functions are called when a userspace program invokes the exec syscall. Its obvious that the kernel should be resistant to a malicious userspace process.
This code is called when a process is exec(), but is kernel code. The purpose of the patch is for example to tell the kernel to crash if user exec() a process at 23:42.


Thanks,

!!! 11-21-2017 11:54 AM

Maybe: look at the kernel code that handles=performs SysRq c
Or maybe (my wild-guess) call panic() in your modified kernel code. Idk, sorry.
p.s. 'Welcome to LQ'.

satanfu 11-21-2017 03:10 PM

Quote:

Originally Posted by !!! (Post 5783481)
p.s. 'Welcome to LQ'.

Thanks mate!

I'll try for the panic and sysrq handlers.

sundialsvcs 11-23-2017 04:15 PM

Quote:

Originally Posted by satanfu (Post 5783267)
Hi sundialsvcs, please read me well. The code I'm patching is kernel sources (fs/exec.c). Those kernel functions are called when a userspace program invokes the exec syscall. Its obvious that the kernel should be resistant to a malicious userspace process.
This code is called when a process is exec(), but is kernel code. The purpose of the patch is for example to tell the kernel to crash if user exec() a process at 23:42.

Seems to me that it ought to kill the requesting process, not burn-down the entire forest.

satanfu 11-25-2017 12:24 PM

Quote:

Originally Posted by !!! (Post 5783481)
Or maybe (my wild-guess) call panic() in your modified kernel code.

panic() did the job.

Many thanks.


All times are GMT -5. The time now is 01:17 PM.