Bug 1507 - [PATCH] ldd segfault fix
Summary: [PATCH] ldd segfault fix
Status: RESOLVED FIXED
Alias: None
Product: uClibc
Classification: Unclassified
Component: Shared Library Support (show other bugs)
Version: 0.9.30.3
Hardware: PC Linux
: P5 minor
Target Milestone: ---
Assignee: Carmelo Amoroso
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-07 07:49 UTC by Natanael Copa
Modified: 2010-05-24 07:10 UTC (History)
1 user (show)

See Also:
Host: x86
Target: x86
Build:


Attachments
0001-ldd-segfault-fix.patch (1.12 KB, patch)
2010-04-07 07:49 UTC, Natanael Copa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Natanael Copa 2010-04-07 07:49:14 UTC
Created attachment 1483 [details]
0001-ldd-segfault-fix.patch

Testcase:

extern void _dl_getenv(void);
void foo(void)
{
        printf("foo: %x\n", &_dl_getenv);
}

linked as -shared

ldd will segfault. Happens on 0.9.30.x and on current nptl.
Comment 1 Carmelo Amoroso 2010-05-19 05:29:09 UTC
Hi Natanael,
I'll give a try on my box too and let you know.
Thanks for the patch.
Comment 2 Carmelo Amoroso 2010-05-19 05:29:24 UTC
Hi Natanael,
I'll give a try on my box too and let you know.
Thanks for the patch.
Comment 3 Salvatore Cro 2010-05-20 14:32:56 UTC
I gave a try on some of our boards and can confirm the issue.
Applying the patch does seem to solve it.
Comment 4 Carmelo Amoroso 2010-05-21 09:57:20 UTC
Hi Natanael,
see my comments inline...


diff --git a/utils/ldd.c b/utils/ldd.c
index 1f1dc25..2cd173c 100644
--- a/utils/ldd.c
+++ b/utils/ldd.c
@@ -576,18 +576,20 @@ static struct library *find_elf_interpreter(ElfW(Ehdr) *ehdr)
 				}
 				newlib->name = NULL;
 				newlib->path = NULL;
-				return NULL;
+				break;

>>> I understand the change above ...
 			}
 		}
-		if (newlib == NULL)
+		if (newlib == NULL) {
 			newlib = malloc(sizeof(struct library));
+			if (newlib)
+				newlib->next = NULL;
+		}

>>> why this one  ? why do you need to initialise the next field...
>>> if !newlib, we returns NULL anyway, so does it matter to set next ?
>>> is this change actually required to fix the segfault you have seen ?
>>> it seems not

 		if (!newlib)
 			return NULL;
 		newlib->name = malloc(strlen(s) + 1);
 		strcpy(newlib->name, s);
 		newlib->path = strdup(newlib->name);
 		newlib->resolved = 1;
-		newlib->next = NULL;
Comment 5 Natanael Copa 2010-05-21 11:36:17 UTC
(In reply to comment #4)

>              }
>          }
> -        if (newlib == NULL)
> +        if (newlib == NULL) {
>              newlib = malloc(sizeof(struct library));
> +            if (newlib)
> +                newlib->next = NULL;
> +        }
> 
> >>> why this one  ? why do you need to initialise the next field...
> >>> if !newlib, we returns NULL anyway, so does it matter to set next ?
> >>> is this change actually required to fix the segfault you have seen ?
> >>> it seems not

Good question. I don't remember. I think you are right. probably not needed.
Comment 6 Carmelo Amoroso 2010-05-21 11:38:56 UTC
(In reply to comment #5)
> (In reply to comment #4)
> 
> >              }
> >          }
> > -        if (newlib == NULL)
> > +        if (newlib == NULL) {
> >              newlib = malloc(sizeof(struct library));
> > +            if (newlib)
> > +                newlib->next = NULL;
> > +        }
> > 
> > >>> why this one  ? why do you need to initialise the next field...
> > >>> if !newlib, we returns NULL anyway, so does it matter to set next ?
> > >>> is this change actually required to fix the segfault you have seen ?
> > >>> it seems not
> 
> Good question. I don't remember. I think you are right. probably not needed.

:) I would apply the minimal required fix, do you agree ?
Comment 7 Natanael Copa 2010-05-21 11:44:53 UTC
(In reply to comment #6)

> :) I would apply the minimal required fix, do you agree ?

yes.
Comment 8 Carmelo Amoroso 2010-05-24 07:10:05 UTC
(In reply to comment #7)
> (In reply to comment #6)
> 
> > :) I would apply the minimal required fix, do you agree ?
> 
> yes.

Fine, fixed on master in commit b2c4199f0fd53c009858e7ce27f932a4ac92bc60

Thanks