On Wed, 21 Jul 2021 at 13:36, Didier Kryn <k...@in2p3.fr> 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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng