C++ Logo


Advanced search

Re: [wg14/wg21 liaison] (SC22WG14.18859) [Fwd: sudo buffer overlow]

From: Uecker, Martin <Martin.Uecker_at_[hidden]>
Date: Sat, 30 Jan 2021 16:06:12 +0000
Am Samstag, den 30.01.2021, 16:01 +0000 schrieb Uecker, Martin:
> Am Samstag, den 30.01.2021, 16:27 +0100 schrieb Corentin via Liaison:
> > On Sat, Jan 30, 2021 at 4:19 PM Arvid Norberg via Liaison <
> > liaison_at_lists.isocpp.org> wrote:
> >
> > > On Sat, Jan 30, 2021 at 2:56 PM Uecker, Martin via Liaison <
> > > liaison_at_lists.isocpp.org> wrote:
> > >
> ...
> >
> > It is probably a stupid question, but, do we not that that VLAs in C++
> > could lead to additional security issues and vulnerabilities caused by hard
> > to handle stack overflows?
> Hard to handle stack overflows are also caused by function calls
> and large objects on the stack. This needs a more generic
> solution (maybe annotations for compile-time guarantees on
> stack usage). For VLAs there is also some existing compiler
> support to prevent this.
> When talking about this issue, it is often overlooked that the
> alternative to placing the VLA on the stack is to place a larger
> fixed size array on the stack. This will use more stack not
> less.
> The other common misconception is that VLAs need to be on
> the stack.

And I forgot to mention that a stack overflow should never
become a security problem. The traditional issue here
is jumping the guard page, but this can be prevented
by compilers implementing stack probing.

A compiler may also decide to place a VLA on the heap
if this size is not known to have a small bound. In
C this is more difficult, but in C++ this should be


Received on 2021-01-30 10:06:18