Take the 2-minute tour ×

I know that copy_to_user/copy_from_user, get_user/put_user functions are for this purpose.

My question is that, given a user space address/pointer, how can I access the data pointed to by the address from the kernel in general?

I can imagine that first I have to make sure the containing page should be in physical memory (instead of in disk).

What is the next step? Can I use *p, where p is the pointer pointing to some user space data, directly to refer to the data?

Or do I have to first invoke kmap to map the containing physical page frame to the kernel virtual address space? Why?

share|improve this question
add comment

4 Answers

The pointer alone is not enough! You need to know which process that pointer "belongs" to.

When the process gets preempted, the pointer points into the address space of another process. The address may not be mapped any more, yadda yadda,

If that process will be the current process when you access the data, then you should use the copy_to_user/copy_from_user functions.

If the process may be scheduled out, you can try to mlock() the page in RAM and find out which is the physical ram address of the page. Whenever you want to access it, you map that physical page into a kernel virtual address.


  • A malicious process can munlock() the page and trick you into accessing a wrong RAM page.
  • I'm not sure mlock() semantics demand the underlining RAM page MUSTN'T change.
  • the kernel should be able to lock a page into RAM, I'm not familiar with the mm subsystem.
share|improve this answer
add comment

Different user space application has different page table. 1) you need to get user space program pid. 2) search addree in the pid's page table.

Below is a sample code to translate user space virtual address's into physical address. It works at x86 platform.

taskpid = find_get_pid(curpid);
task = pid_task(taskpid, PIDTYPE_PID );
mm = get_task_mm(task);

start_vaddr = vaddr;
end_vaddr = 0xC0000000;

while( start_vaddr < end_vaddr){
    u32 end;

    end = (( start_vaddr + PMD_SIZE) & PMD_MASK);

    if( end < start_vaddr || end > end_vaddr)
        end = end_vaddr;

    ret = walk_pgd(start_vaddr, end, mm);
    if(ret != 0){
        printk("ret: %08x \n", ret);

    start_vaddr = end;



paddr = ret;
kaddr = __va(paddr);
share|improve this answer
Good point and the code logic is nice. But I guess there is some hash table or similar data structure that, given a virtual address, helps you locate the physical page quickly. There is a flaw: kaddr = __va(paddr); This line only works when paddr resides in low memory, right? –  SetTimer May 9 '12 at 21:45
paddr means physical address, so, always existed in memory. kaddr means kernel address. In Linux kernel define is #define __va(x) ((void *)((unsigned long)(x)+PAGE_OFFSET)). Kernel address memory mapping is not complex, just a PAGE_OFFSET. (Should be 0xC0000000 at x86 mode). There is other way to get the address. Userspace application can access kernel address with /proc/<pid>/pagemap to get page information. If can get PFN, it also can get kernel address. –  richliu May 14 '12 at 8:59
add comment

You'll need to follow an address to get a corresponding page struct (see follow_page for the example). Next, getting the page struct you'll need to map it to kernel's address space via kmap or kmap_atomic.

share|improve this answer
add comment

You may find this useful.

Let us repeat that the buff argument to the read and write methods is a user-space pointer. Therefore, it cannot be directly dereferenced by kernel code. There are a few reasons for this restriction:

  • Depending on which architecture your driver is running on, and how the kernel was configured, the user-space pointer may not be valid while running in kernel mode at all. There may be no mapping for that address, or it could point to some other, random data.

  • Even if the pointer does mean the same thing in kernel space, user-space memory is paged, and the memory in question might not be resident in RAM when the system call is made. Attempting to reference the user-space memory directly could generate a page fault, which is something that kernel code is not allowed to do. The result would be an "oops," which would result in the death of the process that made the system call.

  • The pointer in question has been supplied by a user program, which could be buggy or malicious. If your driver ever blindly dereferences a user-supplied pointer, it provides an open doorway allowing a user-space program to access or overwrite memory anywhere in the system. If you do not wish to be responsible for compromising the security of your users' systems, you cannot ever dereference a user-space pointer directly.

Source: http://www.makelinux.net/ldd3/chp-3-sect-7

That said, I am myself curious to know what happens if the user-space address is indeed valid, and none of the above conditions apply...

share|improve this answer
add comment

Your Answer


