The -ftrivial-auto-var-init=zero usage guarantees implicit zero
initializers for all stack variables. Thus most bug reports relying
on undefined behaviour from lack of variable initialization will
not be security issues, or even bugs.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 docs/system/security.rst | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/docs/system/security.rst b/docs/system/security.rst
index 52bbf0cc7a..bbc462457e 100644
--- a/docs/system/security.rst
+++ b/docs/system/security.rst
@@ -133,6 +133,16 @@ an issue as a normal bug.
   that affect the level 0 QEMU process. While these bugs should be
   fixed, they will not be triaged as security flaws at this time.
 
+* **uninitialized stack variables**. If the bug scenario relies on
+  undefined behaviour from stack variables that lack explicit
+  initialization, it will not usually be considered a security flaw.
+  The build system adds '-ftrivial-auto-var-init=zero', which is
+  available in both the supported compilers (GCC and CLang) and
+  ensures all stack variables have implicit zero-initializers.
+  This eliminates undefined behaviour and usually gives the
+  correct desired initialization value, eliminating most of the
+  bug scenarios wrt uninitialized stack variables.
+
 * **low severity impact**. As a catch all rule, issues which
   are judged to have a "low" severity impact on the system will
   usually not justify handling as security bugs, nor assignment
-- 
2.55.0

On Thu, Jul 23, 2026 at 1:46 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> The -ftrivial-auto-var-init=zero usage guarantees implicit zero
> initializers for all stack variables. Thus most bug reports relying
> on undefined behaviour from lack of variable initialization will
> not be security issues, or even bugs.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Still worth to explicitly clear or set the variable though, since it's
not standard C otherwise and sometimes 0 is not the correct value.

Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>

> ---
>  docs/system/security.rst | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/docs/system/security.rst b/docs/system/security.rst
> index 52bbf0cc7a..bbc462457e 100644
> --- a/docs/system/security.rst
> +++ b/docs/system/security.rst
> @@ -133,6 +133,16 @@ an issue as a normal bug.
>    that affect the level 0 QEMU process. While these bugs should be
>    fixed, they will not be triaged as security flaws at this time.
>
> +* **uninitialized stack variables**. If the bug scenario relies on
> +  undefined behaviour from stack variables that lack explicit
> +  initialization, it will not usually be considered a security flaw.
> +  The build system adds '-ftrivial-auto-var-init=zero', which is
> +  available in both the supported compilers (GCC and CLang) and
> +  ensures all stack variables have implicit zero-initializers.
> +  This eliminates undefined behaviour and usually gives the
> +  correct desired initialization value, eliminating most of the
> +  bug scenarios wrt uninitialized stack variables.
> +
>  * **low severity impact**. As a catch all rule, issues which
>    are judged to have a "low" severity impact on the system will
>    usually not justify handling as security bugs, nor assignment
> --
> 2.55.0
>
>


-- 
Marc-André Lureau

On Thu, Jul 23, 2026 at 01:59:30PM +0400, Marc-André Lureau wrote:
> On Thu, Jul 23, 2026 at 1:46 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > The -ftrivial-auto-var-init=zero usage guarantees implicit zero
> > initializers for all stack variables. Thus most bug reports relying
> > on undefined behaviour from lack of variable initialization will
> > not be security issues, or even bugs.
> >
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> 
> Still worth to explicitly clear or set the variable though, since it's
> not standard C otherwise and sometimes 0 is not the correct value.

Yes, certainly we should make it explicit for reviewer sanity
if nothing else.


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|