Re: [PATCH] util/error, hw/net/virtio-net: fix NULL pointer dereference in error_vprepend

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Sep 16, 2026 at 04:48:19PM +0300, Николай Зорин wrote:
> Hello!
> 
> This is not AI-generated content. We have a dedicated team of engineers who
> monitor and analyze security events (ranging from ASan/TSan sanitizers to
> PVS-Studio) and perform statistical analysis (from cppcheck to SVACE and
> white bear). This is a strict requirement from our Quality Assurance
> department, which is mandatory for compliance with our government and
> commercial contracts. Unfortunately, I cannot share our internal security
> tools (especially since they are tailored to our environment and won't work
> for you). However, I can share what our engineers flag as potentially
> dangerous cases during their research. Since the patches we submit address
> long-standing vulnerabilities, we have to maintain them on our side for
> years, as they rarely get fixed in your upstream. If you think these
> findings are outdated or redundant, fine.

I don't know. The patches aren't documented to the level where I can
pass judgement. what there is, does not match code.

"We have an internal tool that flags this code as a bug, I'm not telling
you what it is and I have no idea if the patch is right, it makes my
tool shut up and my government happy, figure the rest out yourself" is
not how any of this works.

If you think your changes are important, work with your dedicated team
to figure out how to be prepared to defend them in public.

Good format to follow:

At the moment .... as a result ... but ... so ... and we can not ...
Fix this by ... as a result ...



> I'll try to convince our
> researchers to drop it—letting them know that the upstream developers
> consider this work completely unnecessary.

I merely consider it incomplete and poorly documented.

> P.S. We are backporting these from Debian 10 (even though the current
> release is Debian 13).

Shrug. This is not the tree against which qemu-devel patches are
supposed to be against.

> P.P.S. I used AI for correcting translate (I not good knowled english)
> 
> nice day
> 
> 16.09.2026 15:48, Markus Armbruster пишет:
> > First, please read docs/devel/code-provenance.rst section "Use of
> > AI-generated content".
> > 
> > I'm not looking at the patches, only the commit message.
> > 
> > Николай Зорин <zorin@swemel.ru> writes:
> > 
> > > SWSA#b0709cee-9722-4603-a30c-dc857dc87961
> > > 
> > > The `error_vprepend()` function modifies the error message inside an
> > > existing Error object. However, it only validated if the `errp` pointer
> > > itself was non-NULL, missing a check for whether the underlying Error
> > > object `*errp` is `NULL`.
> > This is nonsense.  error_vprepend() and error_prepend() modify an error.
> > They must not be called when there is none.  The check isn't missing.
> > Adding it makes the functions "work" papers over bugs.
> > 
> > > Calling `error_reportf_err(local_error, ...)` when `local_error` is `NULL`
> > > invokes `error_vprepend(&local_error, ...)`, which subsequently crashes
> > > via a `NULL` pointer dereference during `(*errp)->msg` access.
> > > 
> > > Fix `util/error.c` by adding a defensive `!*errp` check inside
> > > `error_vprepend()`.
> > > 
> > > Additionally, fix the invalid error reporting patterns in
> > > `hw/net/virtio-net.c`:
> > > - In `vhost_user_net_save_state()` and `vhost_user_net_load_state()`, when
> > >     `vhdev == NULL`, calling `error_reportf_err()` with an unallocated/NULL
> > >     `local_error` is incorrect and unsafe. Replace it with a straightforward
> > >     `error_report()` call.
> > Both uses of error_reportf_err() are indeed wrong.
> > 
> > > - Fix a cosmetic double-space typo in "Error loading  back-end state".
> > Worth cleaning up.
> > 
> > > Signed-off-by: Nikolay N Zorin <zorin@swemel.ru>