On Wed, 21 Jul 2021 at 13:36, Didier Kryn <kryn@???> wrote:

>     I want to add to the comments that this alloca() function has been
> added (by gcc ?) to work around a missing feature of the C language:
> dynamic allocation on the stack. This lack has disapeared many years ago
> ( don't know with which version of the C standard)

[…]

According to a man page I happen to have in front of me, “alloca()
appeared in Version 32V AT&T UNIX.”

I've certainly seen it in use on code originally written during the
last millennium for SGI IRIX, and then ported to several other
systems, many years ago.

It was C99 that introduced variable-length arrays, which is, as you
say, also many years ago :)

According to the same man page:

==B<==
BUGS
     alloca() is machine and compiler dependent; its use is discouraged.

     alloca() is slightly unsafe because it cannot ensure that the
pointer returned points to a valid and usable block of memory.  The
     allocation made may exceed the bounds of the stack, or even go
further into other objects in memory, and alloca() cannot determine
     such an error.  Avoid alloca() with large unbounded allocations.

     The use of C99 variable-length arrays and alloca() in the same
function will cause the lifetime of alloca's storage to be limited
     to the block containing the alloca()
==B<==

Here endeth the lesson, certainly. I like the use of “slightly” in
front of the word “unsafe”. Humorous.

The previous CVE from the same team is quite interesting too (and
looks unrelated to systemd, and will need to be fixed in Devuan
kernels).

https://blog.qualys.com/vulnerabilities-threat-research/2021/07/20/sequoia-a-local-privilege-escalation-vulnerability-in-linuxs-filesystem-layer-cve-2021-33909

--
Bill Gallafent.