Summary: | Stack overflow in dlopen | ||
---|---|---|---|
Product: | glibc | Reporter: | SunshineFly <weizhenvul> |
Component: | dynamic-link | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | drepper.fsp, fweimer |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
SunshineFly
2020-09-07 07:17:03 UTC
This is caused by the alloca in dl-load.c during pathname construction. We cannot trivially replace this with malloc because this allocation would leak most of the time because of the way free works for the dl-minimal.c malloc. I'm setting security- (no security impact) because the dlopen argument does not cross a trust boundary. -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill (In reply to Florian Weimer from comment #1) > This is caused by the alloca in dl-load.c during pathname construction. We > cannot trivially replace this with malloc because this allocation would leak > most of the time because of the way free works for the dl-minimal.c malloc. > > I'm setting security- (no security impact) because the dlopen argument does > not cross a trust boundary. > > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael > O'Neill I analyzed the availability of the problem and concluded that it would only cause a crash. I think it's a safety issue. The dlopen path is definitely trusted, since arbitrary code will be executed from any library you dlopen (ELF constructors even if you never call any functions from the library). So this is an ordinary, non-security bug. |