Skip to contentSkip to conversation

staging: ft1000: add a range check in ft1000_ioctl()

PATCH In review Dan Carpenter 2 participants 3 messages May 3, 2013 – May 5, 2013

Subsystems (2)
Staging Kernel janitors
lore
Share & tools
lore

Dan Carpenter

author
#0 lore raw

PATCH 1/1 staging: ft1000: add a range check in ft1000_ioctl()

msglen comes from get_user() so we need to check that it's not too large.

The first element of "pioctl_dpram" is a short which holds the size of the data the user wants. I have chosen a limit which lets us fill the rest of the struct.

Signed-off-by Dan Carpenter <[email protected]>

---
msglen is also apparently network endian? My guess is that we should just delete this code instead of trying to fix it.

drivers/staging/ft1000/ft1000-usb/ft1000_debug.c +2 -0
index 3251d2e..e0056c9 100644
@@ -703,6 +703,8 @@ static long ft1000_ioctl (struct file *file, unsigned int command,
 			break;
 		msglen = htons(msglen);
                 //DEBUG("FT1000:ft1000_ioctl:msg length = %x\n", msglen);
+		if (msglen > sizeof(*pioctl_dpram) - sizeof(short))
+			msglen = sizeof(*pioctl_dpram) - sizeof(short);
                 if(copy_to_user (&pioctl_dpram->pseudohdr, pdpram_blk->pbuffer, msglen))
 				{
 					DEBUG("FT1000:ft1000_ioctl: copy fault occurred\n");
#1 lore raw
Quoted 17 lines · Dan Carpenter

msglen comes from get_user() so we need to check that it's not too large.

The first element of "pioctl_dpram" is a short which holds the size of the data the user wants. I have chosen a limit which lets us fill the rest of the struct.

Signed-off-by Dan Carpenter <[email protected]>

---
msglen is also apparently network endian? My guess is that we should just delete this code instead of trying to fix it.

drivers/staging/ft1000/ft1000-usb/ft1000_debug.c +0 -0
index 3251d2e..e0056c9 100644

drivers/staging/ft1000/ft1000-usb/ft1000_debug.c static long ft1000_ioctl (struct file *file, unsigned int command, · line 707

Quoted 5 lines
drivers/staging/ft1000/ft1000-usb/ft1000_debug.c +2 -0
@@ -703,6 +703,8 @@ static long ft1000_ioctl (struct file *file, unsigned int command,
                        break;
                msglen = htons(msglen);
                 //DEBUG("FT1000:ft1000_ioctl:msg length = %x\n", msglen);
+               if (msglen > sizeof(*pioctl_dpram) - sizeof(short))
+                       msglen = sizeof(*pioctl_dpram) - sizeof(short);

doing this may be wrong too? because its in network endian format. does deleting msglen = htons(msglen)
and adding your change makes sense?

Quoted 3 lines
drivers/staging/ft1000/ft1000-usb/ft1000_debug.c +0 -0
                 if(copy_to_user (&pioctl_dpram->pseudohdr, pdpram_blk->pbuffer, msglen))
                                {
                                        DEBUG("FT1000:ft1000_ioctl: copy fault occurred\n");
author
#2 lore raw
In reply to Dan Carpenter
Quoted 13 lines · devendra.aaru
Quoted 12 lines · Dan Carpenter

msglen comes from get_user() so we need to check that it's not too large.

The first element of "pioctl_dpram" is a short which holds the size of the data the user wants. I have chosen a limit which lets us fill the rest of the struct.

Signed-off-by Dan Carpenter <[email protected]>

---
msglen is also apparently network endian? My guess is that we should just delete this code instead of trying to fix it.

Quoted 14 lines

drivers/staging/ft1000/ft1000-usb/ft1000_debug.c static long ft1000_ioctl (struct file *file, unsigned int command, · line 707

Quoted 10 lines
drivers/staging/ft1000/ft1000-usb/ft1000_debug.c +2 -0
index 3251d2e..e0056c9 100644
@@ -703,6 +703,8 @@ static long ft1000_ioctl (struct file *file, unsigned int command,
                        break;
                msglen = htons(msglen);
                 //DEBUG("FT1000:ft1000_ioctl:msg length = %x\n", msglen);
+               if (msglen > sizeof(*pioctl_dpram) - sizeof(short))
+                       msglen = sizeof(*pioctl_dpram) - sizeof(short);

doing this may be wrong too? because its in network endian format. does deleting msglen = htons(msglen)
and adding your change makes sense?

Yeah. Probably my patch doesn't make sense by itself.

It's hard to say what the right thing is here without having a way to test it or knowing what userspace does.

I do suspect that the right thing is to just delete this code.

regards,
dan carpenter