[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 16 Jan 2015 22:59:33 +0100
From: Sebastian Gottschall <s.gottschall@...wrt.com>
To: musl@...ts.openwall.com
Subject: Re: pthreads broken (freeradius testcase)
Am 16.01.2015 um 19:09 schrieb Rich Felker:
> On Fri, Jan 16, 2015 at 06:57:45PM +0100, Sebastian Gottschall wrote:
>> Am 16.01.2015 um 17:25 schrieb Rich Felker:
>>> On Fri, Jan 16, 2015 at 12:44:51PM +0100, Sebastian Gottschall wrote:
>>>> Am 16.01.2015 um 08:20 schrieb Natanael Copa:
>>>>> On Thu, 15 Jan 2015 23:52:36 +0100
>>>>> Sebastian Gottschall <s.gottschall@...wrt.com> wrote:
>>>>>
>>>>>> following test case
>>>>>>
>>>>>> configure freeradius with --with-threads (which is on by default)
>>>>>> if you start radiusd with your radius configuration you will see that
>>>>>> radius does not listen on any ports. it will hang in the listener thread
>>>>>> which creates the socket.
>>>>>> if you configure it as --without-threads, it works
>>>>>>
>>>>>>
>>>>>> tested with musl 1.1.6 on a mips (big endian) system using kernel 3.10
>>>>>>
>>>>>> Sebastian
>>>>> What version of freeradius is it?
>>>>>
>>>>> I have had some interesting threading issues with freeradius 2.2.x.
>>>>> Some modules are marked as non-thread safe but will still run in a
>>>>> separate thread. It runs main thread + a single non-thread-safe thread.
>>>>>
>>>>> They used getgrnam and getpwnam in both main thread and in the
>>>>> non-thread-safe module so memory got corrupted. (IMHO this should get a
>>>>> CVE but upstream disagrees because it only happens on a non-recommended
>>>>> config)
>>>>>
>>>>> They fixed that in 3.x.x but AFAIK they didn't fix it in 2.x.x.
>>>>>
>>>>> Patches:
>>>>> http://git.alpinelinux.org/cgit/aports/tree/main/freeradius/0001-Use-threadsafe-wrapper-for-getpwnam-getgrnam.patch
>>>>> http://git.alpinelinux.org/cgit/aports/tree/main/freeradius/0001-use-threadsafe-rad_getgrnam.patch
>>>>>
>>>>> (upstream patched it differently in 3.x.x branch)
>>>>>
>>>>> When backporting the fix to 2.x.x I also found that the TLS configure
>>>>> test is completely broke in 2.x.x branch too. IIRC it will say "TLS
>>>>> found" but behind the scenes it will still disable TLS support.
>>>>>
>>>>> patch:
>>>>> http://git.alpinelinux.org/cgit/aports/tree/main/freeradius/fix-tls-test.patch
>>>>>
>>>>> This is probably not the related the issue you have have at hand, but
>>>>> I'm would not be surprised if musl libc has unmasked another bug in
>>>>> freeradius.
>>>> i applied all these fixes. the first thread for port 1812 works, the
>>>> second thread for internal tunnel 18120 doesnt work
>>>> an hangs again. even if setuid support is disabled
>>> Could you report where the hang is occurring (using gdb backtrace) now
>>> with the setuid support disabled?
>> i will try my best to find it out. gdb is hard to run on embedded
>> shrinked to death the firmware. :-)
> If you're familiar with debugging, it might be possible to determine
> where the threads are hung without gdb. /proc/$pid/task/$tid/stat
> should contain as field 30 the last-observed program-counter (aka
> instruction pointer) for the thread, which can be translated into a
> function address using your binaries and possibly the contents of
> /proc/self/maps. This won't give a full backtrace, but combined with
> the output of the strace utility it might give a good idea what code
> was running when it hung.
>
> If the above all sounds like [insert language you can't speak] to you,
> though, you're probably best sticking to getting gdb running on it.
i'm pretty good in finding out such issues, even with the old printf way.
will try it with the stats way, even if it will likelly point to a musl
libc function. so a stack backtrace would be better to see the caller
location
>
> Rich
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
