Some useful debugging options:
CONFIG_DEBUG_STACK_USAGE
CONFIG_DEBUG_STACKOVERFLOW
if you take enough large array so as to hit the heap
area at that present moment (they both grow towards each other)
I doubt if it is true for kernel mode stack. Kernel stack allocation is
plain pages allocation using zone buddy allocator (alloc_pages_node), so
what is beyond that page, allocated to something else or not is really not
predictable. However one thing which is predictable (and other people have
pointed out as well) is overrunning thread_info struct of the current task.
Also this overrun may not show up with this simple module, because there is
no need to access thread_info here. My suggestions:
1. Try putting a schedule call after overrunning thread_info structure,
thread_info might be accessed while scheduling back current process.
2. Try to access current macro after overrun, it will try do access
corrupt thread_info structure to get task_struct pointer.
But make sure to corrupt the thread_info structure in predictive manner as
pointed out in previous mails :).
-Rajat
On Sun, Sep 16, 2012 at 10:35 AM, Shreyansh Jain shrey.li...@gmail.com
wrote:
Hi 卜弋天 and list,
Please find my comments inline
On Thu, Sep 13, 2012 at 7:38 PM, 卜弋天 bu...@live.cn wrote:
i don't know why you want to corrupt kernel stack by using this method,
stack usually grow from high address to low address,
if you allocate a buff in a function then use memset(), it is writing
data
from low address to high address.
in your implementation, you allocate an array with 8000*4=32000 bytes (
int
arr[8000]; ), then you try to corrupt stack by using memset(), which
operate
memory by bytes, rather than by int. so this memset() only corrupt the
first
8192 bytes of the buffer, which is far away from your current task stack.
thread_info locates at the bottom of current task's stack, please
reference the source code of current_thread_info() function of your
platform. i think it is true for X86 or ARM.
if you really want to corrupt current kernel task's stack, please
try
below code, i did't test it but i think it should work, at least you can
find something from the log:
char *sp_addr;
struct thread_info *thread = current_thread_info();
sp_addr = (char*)thread;
printk(sp_addr==thread:%p, task:%p\n, thread, thread-task);
memset (sp_addr, 0x0, 1024);
printk(after corrupt, task:%p, it is dying...\n, thread-task);
Actually, after reading through the first authors email, it seems he
is trying to find the answer to How much is maximum allocatable space
on the Kernel Stack (Shubham, please correct me if I am wrong).
In that essence what you have mentioned above is more of a direct
method of corrupting the thread_info structure - a definitive stack
corruption.
Date: Thu, 13 Sep 2012 15:32:05 +0530
Subject: Re: kernel stack memory
From: mujeeb.a...@gmail.com
To: getaru...@gmail.com
CC: shubham20...@gmail.com; kernelnewbies@kernelnewbies.org
Hi,
On Thu, Sep 13, 2012 at 1:59 PM, Arun KS getaru...@gmail.com wrote:
Hello Shubham,
On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma
shubham20...@gmail.com
wrote:
Hi,
As far as i know, the size of stack allocated in the kernel space is
8Kb for each process. But in case i use more than 8Kb of memory from
the stack then what will happen? I think that in that case the system
would crash because i am accessing an illegal memory area. I wrote
kernel module in which i defined an integer array whose size was
8000.
But still it did not crash my system. Why?
The module i wrote was as follows:
#include linux/kernel.h
#include linux/module.h
int __init init_my_module(void)
{
int arr[8000];
printk(%s:%d\tmodule initilized\n, __func__, __LINE__);
arr[1] = 1;
arr[4000] = 1;
arr[7999] = 1;
Instead do a memset.
memset(arr, 0, 8192);
If you do this the current calling process thread_info will be set to
zero.
This should cause a crash.
I tried and this is also not causing any crash.
Thanks,
Adil
Thanks,
Arun
printk(%s:%d\tarr[1]:%d, arr[4000]:%d, arr[7999]:%d\n, __func__,
__LINE__, arr[1], arr[4000], arr[7999]);
return 0;
}
void __exit cleanup_my_module(void)
{
printk(exiting\n);
return;
}
module_init(init_my_module);
module_exit(cleanup_my_module);
MODULE_LICENSE(GPL);
Though I don't have an exact answer, but what I understand is that
there is no limit imposed by the kernel while writing in the kernel
layer (as Kshemendra's first post pointed out). Thus, you keep writing
what you wish till either you corrupt the next instruction set or some
data structure which would be read somewhere in future (at that time
what can happen is undefined). Assuming this understanding is some
what correct, if you take enough large array so as to hit the heap
area at that present moment (they both grow towards each other), you
can have a undefined
