CODEWITHSUNDEEP
memory-managementlinux-kernellinux-device-driver
Splaty
Splaty

Reputation: 634

Successfully de-referenced userspace pointer in kernel space without using copy_from_user()

There's a bug in a driver within our company's codebase that's been there for years. Basically we make calls to the driver via ioctls. The data passed between userspace and driver space is stored in a struct, and the pointer to the data is fed into the ioctl. The driver is responsible to dereference the pointer by using copy_from_user(). But this code hasn't been doing that for years, instead just dereferencing the userspace pointer. And so far (that I know of) it hasn't caused any issues until now.

I'm wondering how this code hasn't caused any problems for so long? In what case will dereferencing a pointer in kernel space straight from userspace not cause a problem?

In userspace

struct InfoToDriver_t data;
data.cmd = DRV_SET_THE_CLOCK;
data.speed = 1000;

ioctl(driverFd, DEVICE_XX_DRIVER_MODIFY, &data);

In the driver

device_xx_driver_ioctl_handler (struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg)
{
    struct InfoToDriver_t *user_data;

    switch(cmd)
    {
        case DEVICE_XX_DRIVER_MODIFY:
            // what we've been doing for years, BAD
            // But somehow never caused a kernel oops until now
            user_data = (InfoToDriver_t *)arg;
            if (user_data->cmd == DRV_SET_THE_CLOCK)
            { .... }

            // what we're supposed to do
            copy_from_user(user_data, (void *)arg, sizeof(InfoToDriver_t));
            if (user_data->cmd == DRV_SET_THE_CLOCK)
            { ... }

Upvotes: 1

Views: 1315

Answers (1)

ddbug
ddbug

Reputation: 1539

A possible answer is, this depends on the architecture. As you have seen, on a sane architecture (such as x86 or x86-64) simply dereferencing __user pointers just works. But Linux pretends to support every possible architecture, there are architectures where simple dereference does not work. Otherwise copy_to/from_user won't existed.

Another reason for copy_to/from_user is possibility that usermode side modifies its memory simultaneously with the kernel side (in another thread). You cannot assume that the content of usermode memory is frozen while accessing it from kernel. Rougue usermode code can use this to attack the kernel. For example, you can probe the pointer to output data before executing the work, but when you get to copy the result back to usermode, this pointer is already invalid. Oops. The copy_to_user API ensures (should ensure) that the kernel won't crash during the copy, instead the guilty application will be killed.

A safer approach is to copy the whole usermode data structure into kernel (aka 'capture'), check this copy for consistency.

The bottom line... if this driver is proven to work well on certain architecture, and there are no plans to port it, there's no urgency to change it. But check carefully robustness of the kernel code, if capture of the usermode data is needed, or problem may arise during copying from usermode.

Upvotes: 3

Related Questions