Jeff Law <jeffreya...@gmail.com> writes: > On 7/9/24 7:12 AM, Christoph Müllner wrote: >> On Tue, Jul 9, 2024 at 3:01 PM Kito Cheng <kito.ch...@sifive.com> wrote: >>> >>> IIRC Jeff mentions that it may introduce buffer overflow if the input >>> string is long enough. >> >> The manpage states: >> If the allocation causes stack overflow, program behavior is undefined. >> >> This was considered reasonable for AArch64: >> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64.cc;h=7f0cc47d0f071de9297068baa85c6d5fc4d7fa5b;hb=HEAD#l19408 >> So, my assumption was that it should be fine for RISC-V as well. >> However, I won't insist on this patch. > The key question is whether or not the length can potentially be > attacker controlled. If so, then alloca is highly unsafe. An attacker > can arrange to alloca a much larger region, with the goal of shifting > the stack into the heap, or performing an under allocation due to > integer overflow+wrapping. > > There's additional problems with alloca, but they're largely mitigated > by stack clash which is typically on at the distro level, thankfully. > > My position is unless there is a highly compelling reason, we should > just avoid alloca. And compelling reasons are few and far between.
FWIW, I agree the use in aarch64 is a mistake. I'll send a patch later. Richard
