Le 21/07/2021 à 18:19, Tomasz Torcz a écrit :
> On Wed, Jul 21, 2021 at 06:00:15PM +0200, Didier Kryn wrote:
>> Le 21/07/2021 à 16:51, Bernard Rosset via Dng a écrit :
>>>> https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
>>> I'll be projecting myself here, but I reckon sharing the original
>>> source rather than journalistic articles whenever possible is best
>>> towards a tech-savvy audience.
>>>
>>> The source (included in above article) is here:
>>> https://blog.qualys.com/vulnerabilities-threat-research/2021/07/20/cve-2021-33910-denial-of-service-stack-exhaustion-in-systemd-pid-1
>>     The code shows the use of strdupa(). There is a family of functions
>> which are extensions of POSIX functions, with the suffix 'a' which
>> allocate space for the returned string from the stack. They are very
>> convenient for lazy programmer, but (slightly ?) dangerous and do not
>> belong to POSIX.
>>
>>     I've found a discussion between a developper and Lennart Poeterring
>> in which LP recommends the addition of this kind of functions in Musl
>> libc (which will certainly never happen).
> That's amusing thought. strdupa() is in Musl:
> http://git.musl-libc.org/cgit/musl/tree/include/string.h#n89
> alloca() is there, too:
> http://git.musl-libc.org/cgit/musl/tree/include/alloca.h
>
    At least strdupa() is just a macro conditionned by #ifedf _GNU_SOURCE.

    Similarly alloca() is #defined as the compiler's built in alloca().

    This is a way to provide the minimal service to people wanting to
link with Musl programs developped for Glibc. I guess the pressure was
too high.

--     Didier