Linux Kernel Line Discipline copy_from_user - c

Question

I have developed a simple line discipline using v4.0.5 of the Linux Kernel, running under Mint Linux.
The tty_ldisc_ops structure looks as follows:
static struct tty_ldisc_ops my_ldisc = {
.owner = THIS_MODULE,
.magic = TTY_LDISC_MAGIC,
.name = "my_ldisc",
.open = my_open,
.close = my_close,
.read = my_read,
.write = my_write,
.ioctl = my_ioctl,
.poll = my_poll,
.receive_buf = my_receive,
.write_wakeup = my_wakeup,
};
The module gets added via insmod my_lkm.ko. I know it's getting added correct as I've used printk to indicate it and can see the message via dmesg. Also, at startup, my userspace application uses ioctl and I have also verified that works via printk.
The problem is, in my_write, copy_from_user always returns a non-zero value indicating that it has failed somehow.
Here is my_write():
static ssize_t my_write(struct tty_struct *tty,
struct file *file,
const unsigned char *buf,
size_t nr)
{
int error = 0;
unsigned char data[MAX]; //MAX is 256
if(!my_tty) {
return -EIO;
}
if(nr > MAX) { //too big
return -ENOMEM;
}
error = copy_from_user(data,buf,nr);
printk("copy_from_user returned %d\n",error);
//here, error is always equal to nr
//(which is 12 in my example application)
if(error==0) {
printk("success\n"); //never get here
return nr;
}
return error;
}
From what I've researched, copy_from_user eventually calls pa_memcpy which does validation of the pointers being used. That validation is failing, but I can't tell why. I don't know see how *buf and data overlap or would cause a fault.
Output from uname -a: Linux mint-linux 4.0.5-040005-generic #201506061639 SMP Sat Jun 6 16:40:45 UTC 2015 UTC x86_64 x86_64 x86_64 GNU/Linux
A snippet of the userspace application is:
#define OPEN_FLAGS (O_RDWR|O_NONBLOCK)
int main(int argc, char **argv)
{
int fd=-1;
int bytes_written= 0;
char device="/dev/ttyUSB0";
unsigned char outbuffer[128]={0};
fd=open(device,OPEN_FLAGS);
//set baud rate, etc., switch to my_ldisc (using N_MOUSE)
outbuffer[0]=0x01;
outbuffer[1]=0x02;
outbuffer[2]=0x03;
outbuffer[3]=0x04;
outbuffer[4]=0x05;
outbuffer[5]=0x06;
outbuffer[6]=0x07;
outbuffer[7]=0x08;
outbuffer[8]=0x09;
outbuffer[9]=0x0A;
outbuffer[10]=0x0B;
outbuffer[11]=0x0C;
bytes_written=write(fd,outbuffer,12);
while(true) {
//...
sleep(1);
}
}
In addition, any access of buf in my_write causes instability in the VM. Even following the tty driver example in the o'reilly linux drivers book like this:
printk(KERN_DEBUG "%s - ", __FUNCTION__);
for(i=0;i<nr;i++)
{
printk("%02x ",buf[i]);
}
printk("\n");
Following Tsyvarev's advice, I printed the pointer in the user space application and the kernel module. They were different which meant I should access the incoming buffer directly. I used printf("%p\n",outbuffer); to do that in user space and the equivalent printk in kernel space.
So, slowing down and testing the module line by line helped me to fix the original problem, which it turns out was a bug in the user space application.
FWIW, the compiler never did give me a warning about the use of __user in the original code. Had it worked the way Tsyvarev suggested it would at compile time, it would have made this a lot easier to track down.

Answer 1

Unlike to .write method of struct file_operations, which accepts pointer to user data, .write method for struct tty_operations accepts pointer to kernel data, and these data shold be accessed via usual methods such as memcpy or even directly.
Modern kernel uses __user attribute for mark user-space data, and this attribute is checked (at compile time) when data is accessed. So having compiler warnings enabled will reveal usage of the data with incorrect origin.