Who should I write to about this OOPS in 2,6,11-mm3?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tony, hi all,

> > I've tracked this to eeprom_read in drivers/i2c/chips/eeprom. I
> > don't know exactly what happens but commenting out this part in
> > eeprom_read():
> >
> >	if (data->nature == VAIO && off < 16 && !capable(CAP_SYS_ADMIN))
> >	{
> > #if 0
> >		int in_row1 = 16 - off;
> >		memset(buf, 0, in_row1);
> >		if (count - in_row1 > 0)
> >			memcpy(buf + in_row1, &data->data[16], count -
> >			       in_row1);
> > #endif
> >
> > at least, prevents the hang.

I think I found the problem. If count is less than in_row1, bad things
will happen with the code above. Shame on me for not noticing when I
wrote it in the first place.

Suggested fix would be:

--- linux-2.6.11.4/drivers/i2c/chips/eeprom.c.orig	2005-03-13 10:00:01.000000000 +0100
+++ linux-2.6.11.4/drivers/i2c/chips/eeprom.c	2005-03-17 19:54:07.000000000 +0100
@@ -130,7 +130,8 @@
 
 	/* Hide Vaio security settings to regular users (16 first bytes) */
 	if (data->nature == VAIO && off < 16 && !capable(CAP_SYS_ADMIN)) {
-		int in_row1 = 16 - off;
+		size_t in_row1 = 16 - off;
+		in_row1 = min(in_row1, count);
 		memset(buf, 0, in_row1);
 		if (count - in_row1 > 0)
 			memcpy(buf + in_row1, &data->data[16], count - in_row1);


Please test and report.

Thanks,
-- 
Jean Delvare



[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux