Re: [patch] applicom: use correct array offset
On Friday 01 March 2013, Dan Carpenter wrote: > We're iterating through abps[] printing information, but here we > use the wrong array index. IndexCard comes from the user and in > this case it was specifically not range checked because we didn't > expect to use it. > > Signed-off-by: Dan Carpenter Acked-by: Arnd Bergmann Wow, that is a crappy driver ;-) Dave Woodhouse was apparently the last person who understood it and had something to do with it, and that was back in the 90s. It looks like the vendor actually has its own (much worse) driver for this product line and only supports more recent cards than our driver does. I doubt that there is anyone using this. Should we just kill the driver? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] applicom: use correct array offset
We're iterating through abps[] printing information, but here we use the wrong array index. IndexCard comes from the user and in this case it was specifically not range checked because we didn't expect to use it. Signed-off-by: Dan Carpenter diff --git a/drivers/char/applicom.c b/drivers/char/applicom.c index 25373df..974321a 100644 --- a/drivers/char/applicom.c +++ b/drivers/char/applicom.c @@ -804,8 +804,8 @@ static long ac_ioctl(struct file *file, unsigned int cmd, unsigned long arg) printk(KERN_INFO "Prom version board %d ... V%d.%d %s", i+1, - (int)(readb(apbs[IndexCard].RamIO + VERS) >> 4), - (int)(readb(apbs[IndexCard].RamIO + VERS) & 0xF), + (int)(readb(apbs[i].RamIO + VERS) >> 4), + (int)(readb(apbs[i].RamIO + VERS) & 0xF), boardname); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] applicom: use correct array offset
We're iterating through abps[] printing information, but here we use the wrong array index. IndexCard comes from the user and in this case it was specifically not range checked because we didn't expect to use it. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/char/applicom.c b/drivers/char/applicom.c index 25373df..974321a 100644 --- a/drivers/char/applicom.c +++ b/drivers/char/applicom.c @@ -804,8 +804,8 @@ static long ac_ioctl(struct file *file, unsigned int cmd, unsigned long arg) printk(KERN_INFO Prom version board %d ... V%d.%d %s, i+1, - (int)(readb(apbs[IndexCard].RamIO + VERS) 4), - (int)(readb(apbs[IndexCard].RamIO + VERS) 0xF), + (int)(readb(apbs[i].RamIO + VERS) 4), + (int)(readb(apbs[i].RamIO + VERS) 0xF), boardname); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] applicom: use correct array offset
On Friday 01 March 2013, Dan Carpenter wrote: We're iterating through abps[] printing information, but here we use the wrong array index. IndexCard comes from the user and in this case it was specifically not range checked because we didn't expect to use it. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Acked-by: Arnd Bergmann a...@arndb.de Wow, that is a crappy driver ;-) Dave Woodhouse was apparently the last person who understood it and had something to do with it, and that was back in the 90s. It looks like the vendor actually has its own (much worse) driver for this product line and only supports more recent cards than our driver does. I doubt that there is anyone using this. Should we just kill the driver? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
