| Summary: | dl-close: if dl-load procedure failed, dl-close doesn't delete the half-cooked objects with DF_1_NODELETE | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Daming Yang <lion> |
| Component: | dynamic-link | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | critical | CC: | fweimer |
| Priority: | P2 | Flags: | fweimer:
security-
|
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | 2018-10-23 00:00:00 | |
| Attachments: | Shell script to reproduce the bug | ||
Would you please review bug 20839 and check if it's the same issue? Thanks. (In reply to Florian Weimer from comment #1) > Would you please review bug 20839 and check if it's the same issue? Thanks. Yes, I think they are exactly the same. *** This bug has been marked as a duplicate of bug 20839 *** |
Created attachment 11361 [details] Shell script to reproduce the bug This will happen when a program loads a plugin linked against DF_1_NODELETE shared objects (e.g. /usr/lib/libglib-2.0.so in my computer) and then failed in initialisation progress (phase?) because of, for example, missing some other shared objects. The half-cooked shared objects will be still in link_map chains. Now, consider another normal object is being loaded, ld.so will try to resolve their symbols in the chains and crash because libglib-2.0.so had not been relocated and many fields remain uninitialised. In fact, it crashes in many ways. In short, even a object is marked as NODELETE, if it has not been completely "loaded", it should be deleted. (A simple reproduce script is attached, you will need a C compiler. Tested on Arch Linux, Ubuntu 18.04, AOSC OS) I am willing to propose a patch in /elf/dl-... but I am not sure about the workflow here.