kfree a pointer "from the middle" causing protection faults

kfree a pointer "from the middle" causing protection faults

[Muni Sekhar]

 [ Please keep me in CC as I'm not subscribed to the list]

Hello,


I am getting protection faults in different kernel modules if I try to
free a pointer "from the middle" for example, look at the following
code:


u8 *buf;


buf = kzalloc( 100 , GFP_KERNEL );

…

buf = buf + 50;

…

Kfree(buf);




I would like to know, why the above code is causing protection faults
in other kernel modules?


Regards,
Sekhar

Re: kfree a pointer "from the middle" causing protection faults

[Jeff Epler]

On Wed, Sep 02, 2015 at 08:32:15PM +0530, Muni Sekhar wrote:
>  [ Please keep me in CC as I'm not subscribed to the list]
> 
> Hello,
> 
> 
> I am getting protection faults in different kernel modules if I try to
> free a pointer "from the middle" for example, look at the following
> code:
[..]

Most memory allocators require the pointer eventually passed to the
freeing function is the same pointer as the one returned from the
allocating function.  This is true for libc malloc/free, for instance.
As far as I know, it is true for the Linux allocators such as kzalloc.
The bug lies in whatever part of linux makes the invalid kfree call.

I have not found any documentation that kernel kzalloc/kfree allow
passing a pointer "from the middle".  For instance,
    These routines are used to dynamically request pointer-aligned chunks of
    memory, like malloc and free do in userspace
    https://www.kernel.org/doc/htmldocs/kernel-hacking/routines-kmalloc.html

If the faulty code that you allude to is in the Linux source then please
say what it is so that developers can fix it.  If it's an out of source
module or kernel patch then contact the supplier of that code.

Jeff

Re: kfree a pointer "from the middle" causing protection faults

[Muni Sekhar]

On Wed, Sep 2, 2015 at 9:39 PM, Jeff Epler <jepler@unpythonic.net> wrote:
> On Wed, Sep 02, 2015 at 08:32:15PM +0530, Muni Sekhar wrote:
>>  [ Please keep me in CC as I'm not subscribed to the list]
>>
>> Hello,
>>
>>
>> I am getting protection faults in different kernel modules if I try to
>> free a pointer "from the middle" for example, look at the following
>> code:
> [..]
>
> Most memory allocators require the pointer eventually passed to the
> freeing function is the same pointer as the one returned from the
> allocating function.  This is true for libc malloc/free, for instance.
> As far as I know, it is true for the Linux allocators such as kzalloc.
> The bug lies in whatever part of linux makes the invalid kfree call.
>
> I have not found any documentation that kernel kzalloc/kfree allow
> passing a pointer "from the middle".  For instance,
>     These routines are used to dynamically request pointer-aligned chunks of
>     memory, like malloc and free do in userspace
>     https://www.kernel.org/doc/htmldocs/kernel-hacking/routines-kmalloc.html
>
> If the faulty code that you allude to is in the Linux source then please
> say what it is so that developers can fix it.  If it's an out of source
> module or kernel patch then contact the supplier of that code.

The faulty code mentioned above is not in the Linux source, I noticed
this behaviour during testing our own module. Thanks for the
clarification Jeff.

>
> Jeff

Re: kfree a pointer "from the middle" causing protection faults

[Dmitry Torokhov]

On Wed, Sep 2, 2015 at 8:02 AM, Muni Sekhar <munisekharrms@gmail.com> wrote:
>  [ Please keep me in CC as I'm not subscribed to the list]
>
> Hello,
>
>
> I am getting protection faults in different kernel modules if I try to
> free a pointer "from the middle" for example, look at the following
> code:
>
>
> u8 *buf;
>
>
> buf = kzalloc( 100 , GFP_KERNEL );
>
> …
>
> buf = buf + 50;
>
> …
>
> Kfree(buf);
>
>
>
>
> I would like to know, why the above code is causing protection faults
> in other kernel modules?

Because you can not make a "hole" in returned memory like that, you
can only free entire block allocated by k*alloc and you need to pass
the original pointer in.

Thanks.

-- 
Dmitry