
Glibc vulnerability was identified in uClibc and fixed 6 years ago - dsl
https://dev.openwrt.org/ticket/6886
======
kazinator
This doesn't look like the same thing at all (as the recently reported glibc
resolver issue):

uClibc fix:
[https://dev.openwrt.org/browser/trunk/toolchain/uClibc/patch...](https://dev.openwrt.org/browser/trunk/toolchain/uClibc/patches-0.9.30.1/902-Fix-
use-after-free-bug-in-__dns_lookup.patch?rev=20384)

glibc fix:
[https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b995d95a...](https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b995d95a5943785be3ab862b2d3276f3b4a22481)

It's totally different code.

~~~
raimue
From the uClibc commit message of the fix:

    
    
      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.

------
geofft
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:

    
    
        titan:~/src/libc/glibc geofft$ git grep __dns_lookup
        titan:~/src/libc/glibc geofft$ git grep 'a->atype'
        titan:~/src/libc/glibc geofft$ git grep '>dotted'
        titan:~/src/libc/glibc geofft$

------
dikaiosune
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?

~~~
stephen_g
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).

~~~
hathawsh
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)

------
pygy_
14 upvotes as I'm typing, so I guess it is relevant, but I can't see how.

Could someone shine more light on this?

~~~
dang
HN Search can:
[https://hn.algolia.com/?query=glibc&sort=byDate&prefix=false...](https://hn.algolia.com/?query=glibc&sort=byDate&prefix=false&page=0&dateRange=all&type=story)
->
[https://news.ycombinator.com/item?id=11109967](https://news.ycombinator.com/item?id=11109967).

~~~
pygy_
Thanks :-)

