For example, the following busybox commands are triggering a segmentation
fault with uClibc 0.9.30.x
- nslookup ipv6.google.com
- ping ipv6.google.com
- wget http//ipv6.google.com/
If this had been the glibc bug, you would have noticed it way earlier.
Yeah, this is not at all the same vulnerability. A segfault in uClibc was fixed 6 years ago. Wasn't the same segfault. Most production C code in the wild has more than one segfault waiting to be found.
The commit message starts out "Fix use-after-free bug in __dns_lookup." First, the glibc thing wasn't a use-after-free; it was all about buffers on the stack. Second, there's no function named __dns_lookup anywhere in glibc, nor any sign that similar code is anywhere to be found:
Can someone provide some context here? Is the OpenWRT libc derived from glibc? If so, why didn't this make it upstream? If not, why is this relevant if they didn't use the same code to start?
uClibc, which was what OpenWRT used as their libc, shared quite a lot of code with glibc. They don't use it anymore because the project is dead though (no releases since 2012, no commits since mid-2015) so they switched to musl, which is looking really nice.
uClibc was mainly trying to be a cut-down version of glibc, but musl aims for correctness (which can be difficult when a fair bit of software out there relies on glibc's quirks and bugs).
Thanks for the tip. For anyone else wondering, OpenWRT 15.05 (Chaos Calmer, the current stable release) is still based on uClibc, while the OpenWRT trunk is now based on musl. (AFAICT)
As Wikipedia puts it, uClibc was mostly written from scratch,[5] but has incorporated code from glibc and other projects.
I didn't bother to check in detail it but it could mean the getaddrinfo() was taken from glibc, and later fixed, but fix not backported to glibc. Just a guess though.
uClibc is a fork of an old and obscure libc, which later incorporated some code from glibc and a few other libc implementations. They're all GPL'd so the mixing of code probably isn't carefully regulated, and figuring out what stuff is appropriate to submit upstream or what is even derived from a particular upstream source is probably not trivial.
uClibc fix: https://dev.openwrt.org/browser/trunk/toolchain/uClibc/patch...
glibc fix: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b995d95a...
It's totally different code.