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

[Markus Armbruster <armbru@redhat.com>]

Николай Зорин <zorin@swemel.ru> writes:

> 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'll try to convince our researchers to drop it—letting them know that the upstream developers consider this work completely unnecessary.
>
> P.S. We are backporting these from Debian 10 (even though the current release is Debian 13).
> P.P.S. I used AI for correcting translate (I not good knowled english)
>
> nice day

When I smell AI, I ask.  This isn't me judging the patch submitter.
It's simply my duty as a maintainer to make a reasonable effort to
ensure patch submitters know what they're doing.

According to the commit message, your patch is about three separate
issues:

1. error_vprepend() crashes when misused

   Yes it does, and that's deliberate.  If you can see a away to get it
   to crash, there's a bug in need of fixing further up the call chain.
   We'd appreciate a patch then.  Alternatively, a reproducer and/or
   stack backtrace, or even static analysis.

2. vhost_user_net_save_state() and vhost_user_net_load_state() misuse
   error_reportf_err()

   They do.  Have you searched for additional instances of this bug?
   Question, not a demand!

3. A cosmetic issue in an error message nearby.

   Yup, there's a double space.  You could go the extra mile and search
   for additional instances.  Again, not a demand.

We prefer one patch per issue, although nearby trivial cleanups can
sometimes be thrown in.  Doing 3 together with 2 is fine.