Am 24.11.2011 12:34, schrieb Dan Carpenter: > On Wed, Nov 23, 2011 at 09:25:56AM +0100, walter harms wrote: >> >> >> Am 23.11.2011 07:42, schrieb Dan Carpenter: >>> These strings come from the user. We strcpy() them inside >>> cf_command() so we should check that they are NULL terminated and >>> return an error if not. >>> >>> Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx> >>> >>> diff --git a/drivers/isdn/divert/divert_procfs.c b/drivers/isdn/divert/divert_procfs.c >>> index 33ec9e4..0c16687 100644 >>> --- a/drivers/isdn/divert/divert_procfs.c >>> +++ b/drivers/isdn/divert/divert_procfs.c >>> @@ -242,6 +242,10 @@ static int isdn_divert_ioctl_unlocked(struct file *file, uint cmd, ulong arg) >>> case IIOCDOCFINT: >>> if (!divert_if.drv_to_name(dioctl.cf_ctrl.drvid)) >>> return (-EINVAL); /* invalid driver */ >>> + if (strlen(dioctl.cf_ctrl.msn) >= sizeof(dioctl.cf_ctrl.msn)) >>> + return -EINVAL; >>> + if (strlen(dioctl.cf_ctrl.fwd_nr) >= sizeof(dioctl.cf_ctrl.fwd_nr)) >>> + return -EINVAL; >> >> forcing the last field to be zero seems more easy. >> dioctl.cf_ctrl.fwd_nr[sizeof(dioctl.cf_ctrl.fwd_nr))-1]=0; >> > > That's a valid option to use, but I'd prefer to return an error code > here because that's what we do on the line before. Passing a too > long string is clearly invalid. > the line before has the same problem, of cause. So far i see you do not get a string, you get a structure. An it will hard to validate the element is a useful string. I thing my (sledgehammer) method is ok here because you make sure that all later calls (strcmp,strcpy) will succeed. If someone supplies a bad string the later calls will catch by failing to identify and return a proper code from there (at least i hope so). re, wh -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
