2008-02-11 17:22:49

by Jean Delvare

[permalink] [raw]
Subject: [PATCH] dmi: Prevent linked list corruption

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 <[email protected]>
Cc: Parag Warudkar <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
---
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


2008-02-11 17:24:50

by Jean Delvare

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

[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 <[email protected]>
Cc: Parag Warudkar <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
---
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

2008-02-11 17:35:58

by Parag Warudkar

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

On Feb 11, 2008 12:24 PM, Jean Delvare <[email protected]> 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 <[email protected]>
> Cc: Parag Warudkar <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Thomas Gleixner <[email protected]>

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 <[email protected]>

Thanks

Parag

2008-02-11 17:54:06

by Jean Delvare

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

Hi Parag,

On Mon, 11 Feb 2008 12:35:39 -0500, Parag Warudkar wrote:
> On Feb 11, 2008 12:24 PM, Jean Delvare <[email protected]> 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 <[email protected]>
> > Cc: Parag Warudkar <[email protected]>
> > Cc: Ingo Molnar <[email protected]>
> > Cc: Thomas Gleixner <[email protected]>
>
> 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 <[email protected]>

Thanks,
--
Jean Delvare