[PATCH] dmi: Prevent linked list corruption

[PATCH] dmi: Prevent linked list corruption

[Jean Delvare]

Adding the same item to a given linked list more than once is guaranteed
to break and corrupt the list. This is however what we do in dmi_scan
since commit 79da4721117fcf188b4b007b775738a530f574da.

Given that there is absolutely no interest in saving empty OEM
strings anyway, I propose the simple and efficient fix below: we
discard the empty OEM strings altogether.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Parag Warudkar <parag.warudkar@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
The empty OEM strings weren't even added with the correct entry type
(0 instead of DMI_DEV_TYPE_OEM_STRING.)

 drivers/firmware/dmi_scan.c |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

--- linux-2.6.25-rc1.orig/drivers/firmware/dmi_scan.c	2008-02-11 16:15:10.000000000 +0100
+++ linux-2.6.25-rc1/drivers/firmware/dmi_scan.c	2008-02-11 18:03:27.000000000 +0100
@@ -217,10 +217,6 @@ static void __init dmi_save_devices(cons
 	}
 }
 
-static struct dmi_device empty_oem_string_dev = {
-	.name = dmi_empty_string,
-};
-
 static void __init dmi_save_oem_strings_devices(const struct dmi_header *dm)
 {
 	int i, count = *(u8 *)(dm + 1);
@@ -229,10 +225,8 @@ static void __init dmi_save_oem_strings_
 	for (i = 1; i <= count; i++) {
 		char *devname = dmi_string(dm, i);
 
-		if (!strcmp(devname, dmi_empty_string)) {
-			list_add(&empty_oem_string_dev.list, &dmi_devices);
+		if (!strcmp(devname, dmi_empty_string))
 			continue;
-		}
 
 		dev = dmi_alloc(sizeof(*dev));
 		if (!dev) {

-- 
Jean Delvare

[PATCH] dmi: Prevent linked list corruption (resent)

[Jean Delvare]

[Once more without forgetting the last "quilt refresh", sorry.]

Adding the same item to a given linked list more than once is guaranteed
to break and corrupt the list. This is however what we do in dmi_scan
since commit 79da4721117fcf188b4b007b775738a530f574da.

Given that there is absolutely no interest in saving empty OEM
strings anyway, I propose the simple and efficient fix below: we
discard the empty OEM strings altogether.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Parag Warudkar <parag.warudkar@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
 drivers/firmware/dmi_scan.c |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

--- linux-2.6.25-rc1.orig/drivers/firmware/dmi_scan.c	2008-02-11 16:15:10.000000000 +0100
+++ linux-2.6.25-rc1/drivers/firmware/dmi_scan.c	2008-02-11 18:04:18.000000000 +0100
@@ -217,10 +217,6 @@ static void __init dmi_save_devices(cons
 	}
 }
 
-static struct dmi_device empty_oem_string_dev = {
-	.name = dmi_empty_string,
-};
-
 static void __init dmi_save_oem_strings_devices(const struct dmi_header *dm)
 {
 	int i, count = *(u8 *)(dm + 1);
@@ -229,10 +225,8 @@ static void __init dmi_save_oem_strings_
 	for (i = 1; i <= count; i++) {
 		char *devname = dmi_string(dm, i);
 
-		if (!strcmp(devname, dmi_empty_string)) {
-			list_add(&empty_oem_string_dev.list, &dmi_devices);
+		if (devname == dmi_empty_string)
 			continue;
-		}
 
 		dev = dmi_alloc(sizeof(*dev));
 		if (!dev) {

-- 
Jean Delvare

Re: [PATCH] dmi: Prevent linked list corruption (resent)

[Parag Warudkar]

On Feb 11, 2008 12:24 PM, Jean Delvare <khali@linux-fr.org> wrote:
> [Once more without forgetting the last "quilt refresh", sorry.]
>
> Adding the same item to a given linked list more than once is guaranteed
> to break and corrupt the list. This is however what we do in dmi_scan
> since commit 79da4721117fcf188b4b007b775738a530f574da.
>
> Given that there is absolutely no interest in saving empty OEM
> strings anyway, I propose the simple and efficient fix below: we
> discard the empty OEM strings altogether.
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Cc: Parag Warudkar <parag.warudkar@gmail.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Thomas Gleixner <tglx@linutronix.de>

I suppose the list would be corrupted only if there are deletions from
the list? (Which there aren't.)

Anyway not adding the empty strings is way better and I don't see now
how they could've been useful.
(I added them out of the doubt of breaking something.)

Acked-By: Parag Warudkar <parag.warudkar@gmail.com>

Thanks

Parag

Re: [PATCH] dmi: Prevent linked list corruption (resent)

[Jean Delvare]

Hi Parag,

On Mon, 11 Feb 2008 12:35:39 -0500, Parag Warudkar wrote:
> On Feb 11, 2008 12:24 PM, Jean Delvare <khali@linux-fr.org> wrote:
> > [Once more without forgetting the last "quilt refresh", sorry.]
> >
> > Adding the same item to a given linked list more than once is guaranteed
> > to break and corrupt the list. This is however what we do in dmi_scan
> > since commit 79da4721117fcf188b4b007b775738a530f574da.
> >
> > Given that there is absolutely no interest in saving empty OEM
> > strings anyway, I propose the simple and efficient fix below: we
> > discard the empty OEM strings altogether.
> >
> > Signed-off-by: Jean Delvare <khali@linux-fr.org>
> > Cc: Parag Warudkar <parag.warudkar@gmail.com>
> > Cc: Ingo Molnar <mingo@elte.hu>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> 
> I suppose the list would be corrupted only if there are deletions from
> the list? (Which there aren't.)

As I understand the way doubly linked lists are implemented in Linux, I
think that the corruption exists even if you are only adding items to
the list. Each struct dmi_device contains a list_head which points to
the previous and next items in the list. If you add a struct dmi_device
that was already in the list, you are overwriting this list_head with
new pointers and you lose the pointers that were originally there. This
means that you have created a "shortcut" from one list item to another
item that is further in the list, and the items in-between them are no
longer reachable.

> Anyway not adding the empty strings is way better and I don't see now
> how they could've been useful.
> (I added them out of the doubt of breaking something.)
> 
> Acked-By: Parag Warudkar <parag.warudkar@gmail.com>

Thanks,
-- 
Jean Delvare