Re: Verify Kernel Pointer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




kfree calls kfree_debugcheck which looks like (I shortened it):

    struct page *page;

    if (!virt_addr_valid(objp))
        BUG();
    page = virt_to_page(objp);
    if (!PageSlab(page))
        BUG();

It seems to me that these are the functions you look for.

Hope you don't mind me asking, but why not keep a table of pointers?
Aren't you afraid that you might encounter a random string that matches your signature?
How many concurrent transactions are you expecting?

Memory-wise speaking, the table pays one more pointer per each block you allocated (= 4 or 8 bytes). I doubt that the signature is shorter than that.

Hayim.


You have understood correctly.

1. I do have signature in allocated memory
2. Also, I compare pid of the calling process and one stored in the
struct

Only thing left is to verify that memory is mapped.

Benefit. Well we have two versions of this kernel application. 1.
with number\uffff (like file descriptor) returned for each transaction and
other this one, where pointer is returned. This to avoid any tytpe of
lookup. Consider 100s of processes each having multiple tractions
(running in 1000s)

Hayim Shaul <hayim@xxxxxxxxxxxxxx> wrote:


Just to make sure I and all understand:

For each transaction of your device you allocate some memory area that stores what-ever. you use the pointer to this area as an identifier of the transaction. So you pass the user the identifier (the user not caring it is actually a pointer). In future references the user passes this identifier. You want to access the memory area allocated for the transaction, which is easy to find as the identifier is actually the pointer.


It seems to me that you have a bigger problem. It is not enough to check that the pointer is valid (i.e. points to an allocated area). You want to check that it is pointing to an area that your module allocated (and not say, the kernel code). Also you want to check that the area was allocated and still in use (i.e. not deallocated), or not allocated for other porpuses (if you have any).

Even if you trust the applications using your module not to change the pointer you give them you should consider this case:
 - the userspace starts a transaction
 - memory allocated
 - transaction finishes
 - memory de-allocated
 - same memory allocated by other part of kernel
- userspace application referenses (by bug) the finished transaction (thus referencing the memory already allocated by someone else)


So all in all, relying on the a pointer given by the user is a bad idea.

Why not keep a table of pointers to memory you allocated and give the user an index to this table?


Theoretically speaking, I guess you can avoid such a table by checking the validity of the pointer you get, and then check that it points to
one of your valid structures by putting some signature in each structure.
However I don't see any practical reason to do so.

On Fri, 21 Apr 2006, Anand H. Krishnan wrote:

Hi



Driver (i.e. my code) allocate memory for each request (through slab
cache).
There could be many transections for each request. (think if you open a
for
file you can do read, write operations).


As Bob said, you should probably consider using file structure for this.

And all I want to make sure that application (by mistake or by choice) is
not passing a junk value to my code. Once, I verify that memory is OK,
than
I can look for signatures to make sure that it is pointing to correct data
structure.


If I've interpreted the above correctly all that you need to do is to verify
whether
the address passed falls in the kernel address space or not. For that the
simple
st of checks that you can do is to see whether the pointer is >PAGE_OFFSET.

Anand

Talib

_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement




+++++++++++++++++++++++++++++++++++++++++++
This Mail Was Scanned By Mail-seCure System
at the Tel-Aviv University CC.



--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux