kernel stack memory

kernel stack memory

[shubham sharma]

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;
	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");

kernel stack memory

[Kshemendra KP]

In user space when you write beyond your address space (if your write
crosses
the page boundary alloacted to you), then process is terminated. In the
kernel
you are still writinng inside the kernel address space. Your write is not
beyond
kernel address space.

Secondly you are corrupting some other data structure. The kernel stack is
part
of task_struct of the running process, a kmalloc or slab allocator might
have
provided this memory (task_-struct).  When you write beyond this if the
write modiefies some crucial data structure that may result in hang or a
crash.




On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma <shubham20006@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;
>         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");
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120913/518a5faf/attachment.html 

kernel stack memory

[shubham sharma]

Hi,

On Thu, Sep 13, 2012 at 12:29 PM, Kshemendra KP
<kshemendra@suphalaam.com> wrote:
>
> In user space when you write beyond your address space (if your write
> crosses
> the page boundary alloacted to you), then process is terminated. In the
> kernel
> you are still writinng inside the kernel address space. Your write is not
> beyond
> kernel address space.
>
> Secondly you are corrupting some other data structure. The kernel stack is
> part
> of task_struct of the running process, a kmalloc or slab allocator might
> have
> provided this memory (task_-struct).  When you write beyond this if the
> write modiefies some crucial data structure that may result in hang or a
> crash.

I did a quick calculation on this. The number of slab objects
allocated for task_struct in my system are 280 and each size of each
object is 3264

---8<---
root at shubh-VirtualBox:~# cat /proc/slabinfo  | grep task_struct
task_struct          262    280   3264   10    8 : tunables    0    0
  0 : slabdata     28     28      0
---8<---

So if my understanding is correct, in case if i define an array of
more than 280*3264 bytes then it will corrupt the task_struct of at
least one significantly important process or@least the task_struct
of the process for my terminal will get corrupted?

>
>
>
>
> On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma <shubham20006@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;
>>         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");
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>

kernel stack memory

[Kshemendra KP]

Not sure for all the tasks slab is created initailly with contiguous
memory. Slab cache
is shrinked when the system is low on memory.

If the memory is contiguous wriring few bytes after the kernel stack may
corrupt a task_struct
of other task and  it may for eg. corrupt the linked list element resuling
in a crash. If it is not
contiguous, then it may corrupt some other data. If the data is crucial
like link or based on
the value some decision is taken then it will crash.  If some statistics
field is overwritten
it may not impact the system stability.





On Thu, Sep 13, 2012 at 12:42 PM, shubham sharma <shubham20006@gmail.com>wrote:

> Hi,
>
> On Thu, Sep 13, 2012 at 12:29 PM, Kshemendra KP
> <kshemendra@suphalaam.com> wrote:
> >
> > In user space when you write beyond your address space (if your write
> > crosses
> > the page boundary alloacted to you), then process is terminated. In the
> > kernel
> > you are still writinng inside the kernel address space. Your write is not
> > beyond
> > kernel address space.
> >
> > Secondly you are corrupting some other data structure. The kernel stack
> is
> > part
> > of task_struct of the running process, a kmalloc or slab allocator might
> > have
> > provided this memory (task_-struct).  When you write beyond this if the
> > write modiefies some crucial data structure that may result in hang or a
> > crash.
>
> I did a quick calculation on this. The number of slab objects
> allocated for task_struct in my system are 280 and each size of each
> object is 3264
>
> ---8<---
> root at shubh-VirtualBox:~# cat /proc/slabinfo  | grep task_struct
> task_struct          262    280   3264   10    8 : tunables    0    0
>   0 : slabdata     28     28      0
> ---8<---
>
> So if my understanding is correct, in case if i define an array of
> more than 280*3264 bytes then it will corrupt the task_struct of at
> least one significantly important process or at least the task_struct
> of the process for my terminal will get corrupted?
>
> >
> >
> >
> >
> > On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma <shubham20006@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;
> >>         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");
> >>
> >> _______________________________________________
> >> Kernelnewbies mailing list
> >> Kernelnewbies at kernelnewbies.org
> >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120913/9981e17f/attachment.html 

kernel stack memory

[Arun KS]

Hello Shubham,

On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma <shubham20006@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.

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");
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120913/1cb5e523/attachment-0001.html 

kernel stack memory

[Rajat Sharma]

"The kernel stack is part of task_struct of the running process"

Please double check that, its not part of task_struct, rather on some
architectures, kernel stack is extended by a thread_info structure at
the end which keeps a link to task_struct of the process.

-Rajat

On Thu, Sep 13, 2012 at 1:59 PM, Arun KS <getarunks@gmail.com> wrote:
> Hello Shubham,
>
> On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma <shubham20006@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.
>
> 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");
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

kernel stack memory

[Adil Mujeeb]

Hi,

On Thu, Sep 13, 2012 at 1:59 PM, Arun KS <getarunks@gmail.com> wrote:
> Hello Shubham,
>
> On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma <shubham20006@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");
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

kernel stack memory

[Denis Kirjanov]

At the moment of forking a new process do_fork() creates a new stack for the
task by using alloc_thread_info_node():

        struct page *page = alloc_pages_node(node, THREADINFO_GFP,
                                             THREAD_SIZE_ORDER);


On 9/13/12, Rajat Sharma <fs.rajat@gmail.com> wrote:
> "The kernel stack is part of task_struct of the running process"
>
> Please double check that, its not part of task_struct, rather on some
> architectures, kernel stack is extended by a thread_info structure at
> the end which keeps a link to task_struct of the process.
>
> -Rajat
>
> On Thu, Sep 13, 2012 at 1:59 PM, Arun KS <getarunks@gmail.com> wrote:
>> Hello Shubham,
>>
>> On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma <shubham20006@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.
>>
>> 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");
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>


-- 
Regards,
Denis

kernel stack memory

[Ashish Sangwan]

Enable this CONFIG_CC_STACKPROTECTOR and you will get crash.
Stack overflow does'nt necessarily creates kernel panic ;)

On Thu, Sep 13, 2012 at 5:00 PM, Denis Kirjanov <kirjanov@gmail.com> wrote:
> At the moment of forking a new process do_fork() creates a new stack for the
> task by using alloc_thread_info_node():
>
>         struct page *page = alloc_pages_node(node, THREADINFO_GFP,
>                                              THREAD_SIZE_ORDER);
>
>
> On 9/13/12, Rajat Sharma <fs.rajat@gmail.com> wrote:
>> "The kernel stack is part of task_struct of the running process"
>>
>> Please double check that, its not part of task_struct, rather on some
>> architectures, kernel stack is extended by a thread_info structure at
>> the end which keeps a link to task_struct of the process.
>>
>> -Rajat
>>
>> On Thu, Sep 13, 2012 at 1:59 PM, Arun KS <getarunks@gmail.com> wrote:
>>> Hello Shubham,
>>>
>>> On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma <shubham20006@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.
>>>
>>> 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");
>>>>
>>>> _______________________________________________
>>>> Kernelnewbies mailing list
>>>> Kernelnewbies at kernelnewbies.org
>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>>
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
>
> --
> Regards,
> Denis
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

kernel stack memory

[卜弋天]

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);

 > Date: Thu, 13 Sep 2012 15:32:05 +0530
> Subject: Re: kernel stack memory
> From: mujeeb.adil at gmail.com
> To: getarunks at gmail.com
> CC: shubham20006 at gmail.com; kernelnewbies at kernelnewbies.org
> 
> Hi,
> 
> On Thu, Sep 13, 2012 at 1:59 PM, Arun KS <getarunks@gmail.com> wrote:
> > Hello Shubham,
> >
> > On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma <shubham20006@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");
> >>
> >> _______________________________________________
> >> Kernelnewbies mailing list
> >> Kernelnewbies at kernelnewbies.org
> >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
> >
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120913/1d1ddcac/attachment-0001.html 

kernel stack memory

[Shreyansh Jain]

Hi ??? and list,

Please find my comments inline

On Thu, Sep 13, 2012 at 7:38 PM, ??? <buyit@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.adil at gmail.com
>> To: getarunks at gmail.com
>> CC: shubham20006 at gmail.com; kernelnewbies at kernelnewbies.org
>
>>
>> Hi,
>>
>> On Thu, Sep 13, 2012 at 1:59 PM, Arun KS <getarunks@gmail.com> wrote:
>> > Hello Shubham,
>> >
>> > On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma
>> > <shubham20006@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 behavior (which may not be instantly visible).

This is all I can add. PCMIIW

Thanks.
Shreyansh

kernel stack memory

[Rajat Sharma]

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.linux@gmail.com>
wrote:
> Hi ??? and list,
>
> Please find my comments inline
>
> On Thu, Sep 13, 2012 at 7:38 PM, ??? <buyit@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.adil at gmail.com
>>> To: getarunks at gmail.com
>>> CC: shubham20006 at gmail.com; kernelnewbies at kernelnewbies.org
>>
>>>
>>> Hi,
>>>
>>> On Thu, Sep 13, 2012 at 1:59 PM, Arun KS <getarunks@gmail.com> wrote:
>>> > Hello Shubham,
>>> >
>>> > On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma
>>> > <shubham20006@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 behavior (which may not be instantly visible).
>
> This is all I can add. PCMIIW
>
> Thanks.
> Shreyansh
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120916/8a9b8d8e/attachment.html 

kernel stack memory

[Shreyansh Jain]

Hi,

On Sun, Sep 16, 2012 at 1:00 PM, Rajat Sharma <fs.rajat@gmail.com> wrote:
> 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:

I agree with the above. It sounds much more logical to me as well. I
made a mistake of thinking the Kernel 1GB as being mapped like an ELF
- which obviously may not be a correct assumption. Thanks for
correcting.

>
> Try putting a schedule call after overrunning thread_info structure,
> thread_info might be accessed while scheduling back current process.
> 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.linux@gmail.com>
> wrote:
>> Hi ??? and list,
>>
>> Please find my comments inline
>>
>> On Thu, Sep 13, 2012 at 7:38 PM, ??? <buyit@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.adil at gmail.com
>>>> To: getarunks at gmail.com
>>>> CC: shubham20006 at gmail.com; kernelnewbies at kernelnewbies.org
>>>
>>>>
>>>> Hi,
>>>>
>>>> On Thu, Sep 13, 2012 at 1:59 PM, Arun KS <getarunks@gmail.com> wrote:
>>>> > Hello Shubham,
>>>> >
>>>> > On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma
>>>> > <shubham20006@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 behavior (which may not be instantly visible).
>>
>> This is all I can add. PCMIIW
>>
>> Thanks.
>> Shreyansh
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

-
Shreyansh