[PULL 0/4] Misc patches queues

[PULL 0/4] Misc patches queues

[Daniel P. Berrangé]

The following changes since commit 94826ec1370328375c3b6d1e80fdc94c8f46c348:

  Merge tag 'accel-20260706' of https://github.com/philmd/qemu into staging (2026-07-06 18:38:14 +0200)

are available in the Git repository at:

  https://gitlab.com/berrange/qemu tags/misc-next-pull-request

for you to fetch changes up to 64d0d2efdd2822c827aa7cd276e15c7cefaccb95:

  docs: outline some guidelines for security classification (2026-07-07 18:36:15 +0100)

----------------------------------------------------------------
* Outline security classification guidelines
* Use QEMU lock guards in inotify code
* Fix certificate error checking

----------------------------------------------------------------

Daniel P. Berrangé (1):
  docs: outline some guidelines for security classification

Evgeny Kolmakov (1):
  util/filemonitor-inotify: Use QEMU_LOCK_GUARD()

Peter Maydell (1):
  io/channel-socket: Document why we can ignore socket_set_cork() errors

yujun (1):
  crypto/x509-utils: fix gnutls error code in crt_init failure path

 crypto/x509-utils.c        |  3 +-
 docs/system/security.rst   | 63 ++++++++++++++++++++++++++++++++++++++
 io/channel-socket.c        |  6 ++++
 util/filemonitor-inotify.c | 28 +++++------------
 4 files changed, 79 insertions(+), 21 deletions(-)

-- 
2.55.0

[PULL 1/4] crypto/x509-utils: fix gnutls error code in crt_init failure path

[Daniel P. Berrangé]

From: yujun <yujun@kylinos.cn>

qcrypto_get_x509_cert_fingerprint() reports gnutls_strerror(ret) when
gnutls_x509_crt_init() fails, but ret is still the initial value -1.
Store the gnutls return code before formatting the error, matching
other gnutls call sites in the tree.

Fixes: 2183ab6251 ("crypto/x509-utils: Check for error from gnutls_x509_crt_init()")
Signed-off-by: yujun <yujun@kylinos.cn>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 crypto/x509-utils.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/crypto/x509-utils.c b/crypto/x509-utils.c
index 39bb6d4d8c..1843488bca 100644
--- a/crypto/x509-utils.c
+++ b/crypto/x509-utils.c
@@ -46,7 +46,8 @@ int qcrypto_get_x509_cert_fingerprint(uint8_t *cert, size_t size,
         return -1;
     }
 
-    if (gnutls_x509_crt_init(&crt) < 0) {
+    ret = gnutls_x509_crt_init(&crt);
+    if (ret < 0) {
         error_setg(errp, "Unable to initialize certificate: %s",
                    gnutls_strerror(ret));
         return -1;
-- 
2.55.0

[PULL 2/4] util/filemonitor-inotify: Use QEMU_LOCK_GUARD()

[Daniel P. Berrangé]

From: Evgeny Kolmakov <randomjack94dev@gmail.com>

Replace manual qemu_mutex_(un)lock() calls with
QEMU_LOCK_GUARD() to remove 'goto cleanup' code

Signed-off-by: Evgeny Kolmakov <randomjack94dev@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 util/filemonitor-inotify.c | 28 ++++++++--------------------
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/util/filemonitor-inotify.c b/util/filemonitor-inotify.c
index 7352b9fe53..fe2057f820 100644
--- a/util/filemonitor-inotify.c
+++ b/util/filemonitor-inotify.c
@@ -21,6 +21,7 @@
 #include "qemu/osdep.h"
 #include "qemu/filemonitor.h"
 #include "qemu/main-loop.h"
+#include "qemu/lockable.h"
 #include "qemu/error-report.h"
 #include "qapi/error.h"
 #include "trace.h"
@@ -59,10 +60,9 @@ static void qemu_file_monitor_watch(void *arg)
     int used = 0;
     int len;
 
-    qemu_mutex_lock(&mon->lock);
+    QEMU_LOCK_GUARD(&mon->lock);
 
     if (mon->fd == -1) {
-        qemu_mutex_unlock(&mon->lock);
         return;
     }
 
@@ -72,11 +72,10 @@ static void qemu_file_monitor_watch(void *arg)
         if (errno != EAGAIN) {
             error_report("Failure monitoring inotify FD '%s',"
                          "disabling events", strerror(errno));
-            goto cleanup;
         }
 
         /* no more events right now */
-        goto cleanup;
+        return;
     }
 
     /* Loop over all events in the buffer */
@@ -151,9 +150,6 @@ static void qemu_file_monitor_watch(void *arg)
             }
         }
     }
-
- cleanup:
-    qemu_mutex_unlock(&mon->lock);
 }
 
 
@@ -257,9 +253,8 @@ qemu_file_monitor_add_watch(QFileMonitor *mon,
 {
     QFileMonitorDir *dir;
     QFileMonitorWatch watch;
-    int64_t ret = -1;
 
-    qemu_mutex_lock(&mon->lock);
+    QEMU_LOCK_GUARD(&mon->lock);
     dir = g_hash_table_lookup(mon->dirs, dirpath);
     if (!dir) {
         int rv = inotify_add_watch(mon->fd, dirpath,
@@ -268,7 +263,7 @@ qemu_file_monitor_add_watch(QFileMonitor *mon,
 
         if (rv < 0) {
             error_setg_errno(errp, errno, "Unable to watch '%s'", dirpath);
-            goto cleanup;
+            return -1;
         }
 
         trace_qemu_file_monitor_enable_watch(mon, dirpath, rv);
@@ -297,11 +292,7 @@ qemu_file_monitor_add_watch(QFileMonitor *mon,
                                       filename ? filename : "<none>",
                                       cb, opaque, watch.id);
 
-    ret = watch.id;
-
- cleanup:
-    qemu_mutex_unlock(&mon->lock);
-    return ret;
+    return watch.id;
 }
 
 
@@ -312,13 +303,13 @@ void qemu_file_monitor_remove_watch(QFileMonitor *mon,
     QFileMonitorDir *dir;
     gsize i;
 
-    qemu_mutex_lock(&mon->lock);
+    QEMU_LOCK_GUARD(&mon->lock);
 
     trace_qemu_file_monitor_remove_watch(mon, dirpath, id);
 
     dir = g_hash_table_lookup(mon->dirs, dirpath);
     if (!dir) {
-        goto cleanup;
+        return;
     }
 
     for (i = 0; i < dir->watches->len; i++) {
@@ -342,7 +333,4 @@ void qemu_file_monitor_remove_watch(QFileMonitor *mon,
             qemu_set_fd_handler(mon->fd, NULL, NULL, NULL);
         }
     }
-
- cleanup:
-    qemu_mutex_unlock(&mon->lock);
 }
-- 
2.55.0

[PULL 3/4] io/channel-socket: Document why we can ignore socket_set_cork() errors

[Daniel P. Berrangé]

From: Peter Maydell <peter.maydell@linaro.org>

In qio_channel_socket_set_cork(), we call socket_set_cork() but
ignore its success/failure return value.  This is OK because we are
implementing qio_channel_set_cork() here, and that function's API
documentation states that the setting is merely a hint.  So even if
setting TCP_CORK on the underlying socket fails for some reason, this
isn't going to be a problem for the caller; correspondingly the
qio_channel_set_cork() function has no error return.

Add a comment in qio_channel_socket_set_cork() explaining why we
don't check for errors.

Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/2254
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 io/channel-socket.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/io/channel-socket.c b/io/channel-socket.c
index ea2ec84108..12773b832c 100644
--- a/io/channel-socket.c
+++ b/io/channel-socket.c
@@ -946,6 +946,12 @@ qio_channel_socket_set_cork(QIOChannel *ioc,
     QIOChannelSocket *sioc = QIO_CHANNEL_SOCKET(ioc);
     int v = enabled ? 1 : 0;
 
+    /*
+     * We can ignore the error return from socket_set_cork() because
+     * at the QIO API level set_cork is only a hint, and so
+     * qio_channel_set_cork() can never fail even if it didn't
+     * actually do anything.
+     */
     socket_set_cork(sioc->fd, v);
 }
 
-- 
2.55.0

[PULL 4/4] docs: outline some guidelines for security classification

[Daniel P. Berrangé]

Beyond the overall virt/non-virt use case classification, there are
a number of scenarios which we have decided will not be treated as
security issues. Start to document some of these to give consistency
in our treatment of incoming disclosures.

Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Mauro Matteo Cascella <mcascell@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 docs/system/security.rst | 63 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/docs/system/security.rst b/docs/system/security.rst
index 53992048e6..52bbf0cc7a 100644
--- a/docs/system/security.rst
+++ b/docs/system/security.rst
@@ -75,6 +75,69 @@ Bugs affecting the non-virtualization use case are not considered security
 bugs at this time.  Users with non-virtualization use cases must not rely on
 QEMU to provide guest isolation or any security guarantees.
 
+Security boundary scope
+'''''''''''''''''''''''
+
+Even where a flaw affects the virtualization use case described above,
+not all scenarios will be considered in scope. The following guidelines
+are used to evaluate whether to apply the full security process, or treat
+an issue as a normal bug.
+
+* **assert** / **abort**. If triggering the code path requires kernel
+  privileges (or root account access) in the guest, asserts/aborts in
+  QEMU are a self inflicted denial of service. These will **not** be
+  treated as security flaws, at most hardening bugs. If triggering the
+  code path can be done by an unprivileged guest OS account, this
+  **may** justify handling as a security bug.
+
+* **vhost-user/vfio-user backends**. The backend processes have
+  shared memory regions co-mapped with the QEMU process. The intent
+  of the process separation is operational resilience & flexibility
+  and allowing for independent software suppliers. There is not
+  considered to be security boundary between QEMU and the vhost-user
+  & vfio-user backends. Thus flaws in the backends which can cause
+  crashes / undesirable behaviour in QEMU will **not** be treated as
+  security flaws, but should be fixed as hardening bugs.
+
+* **memory allocation bounds**. There are many ways in which a QEMU
+  process can legitimately consume an amount of memory that is
+  significantly larger than the assigned guest RAM. QEMU's worst
+  case memory usage should be considered effectively unbounded. As
+  such the QEMU deployment on the host should account for the
+  possibility of large memory peaks and apply countermeasures to
+  provide continuity of host operations. It is typical for the Linux
+  OOM killer to reap the process triggering host memory overcommit
+  in the case of exccessive usage, offering a degree of protection.
+  As such, bugs which can lead to excessive/unbounded memory allocations
+  will usually not be classified as security flaws, but should be
+  fixed as hardening bugs.
+
+* **degraded guest behaviour**. There are a set of bugs which can
+  lead guest hardware devices to misbehave. For example, a flawed
+  virtual IOMMU operation may not offer the guest device isolation
+  that would otherwise be expected. If a guest triggered exploit
+  requires kernel privileges (or root account access), and leads
+  to sub-optimal behaviour of the virtual device this is considered
+  a self inflicted service degradation. These will **not** be
+  treated as security flaws, at most hardening bugs. If triggering
+  the code path can be done by an unprivileged guest OS account,
+  this may justify handling as a security bug.
+
+* **nested virtualization**. The scope for nested virtualization
+  is to prevent a level 2 guest from breaking out into a level
+  1 guest. As noted above, a number of scenarios exclude security
+  handling for flaws only exploitable by the guest kernel / root
+  account with affect the guest's own service/availability. In the
+  context of nested virtualization with PCI device assignment, it
+  may may be possible for a level 2 guest kernel to trigger flaws
+  that affect the level 0 QEMU process. While these bugs should be
+  fixed, they will not be triaged as security flaws at this time.
+
+* **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
+  of CVEs. They will be fixed as routine bugs when time allows.
+
 Architecture
 ------------
 
-- 
2.55.0

Re: [PULL 4/4] docs: outline some guidelines for security classification

[Michael S. Tsirkin]

On Tue, Jul 07, 2026 at 06:50:27PM +0100, Daniel P. Berrangé wrote:
> Beyond the overall virt/non-virt use case classification, there are
> a number of scenarios which we have decided will not be treated as
> security issues. Start to document some of these to give consistency
> in our treatment of incoming disclosures.
> 
> Reviewed-by: Thomas Huth <thuth@redhat.com>
> Reviewed-by: Cédric Le Goater <clg@redhat.com>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: Mauro Matteo Cascella <mcascell@redhat.com>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  docs/system/security.rst | 63 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 63 insertions(+)
> 
> diff --git a/docs/system/security.rst b/docs/system/security.rst
> index 53992048e6..52bbf0cc7a 100644
> --- a/docs/system/security.rst
> +++ b/docs/system/security.rst
> @@ -75,6 +75,69 @@ Bugs affecting the non-virtualization use case are not considered security
>  bugs at this time.  Users with non-virtualization use cases must not rely on
>  QEMU to provide guest isolation or any security guarantees.
>  
> +Security boundary scope
> +'''''''''''''''''''''''
> +
> +Even where a flaw affects the virtualization use case described above,
> +not all scenarios will be considered in scope. The following guidelines
> +are used to evaluate whether to apply the full security process, or treat
> +an issue as a normal bug.
> +
> +* **assert** / **abort**. If triggering the code path requires kernel
> +  privileges (or root account access) in the guest, asserts/aborts in
> +  QEMU are a self inflicted denial of service. These will **not** be
> +  treated as security flaws, at most hardening bugs. If triggering the
> +  code path can be done by an unprivileged guest OS account, this
> +  **may** justify handling as a security bug.
> +
> +* **vhost-user/vfio-user backends**. The backend processes have
> +  shared memory regions co-mapped with the QEMU process. The intent
> +  of the process separation is operational resilience & flexibility
> +  and allowing for independent software suppliers. There is not
> +  considered to be security boundary between QEMU and the vhost-user
> +  & vfio-user backends. Thus flaws in the backends which can cause
> +  crashes / undesirable behaviour in QEMU will **not** be treated as
> +  security flaws, but should be fixed as hardening bugs.
> +
> +* **memory allocation bounds**. There are many ways in which a QEMU
> +  process can legitimately consume an amount of memory that is
> +  significantly larger than the assigned guest RAM. QEMU's worst
> +  case memory usage should be considered effectively unbounded. As
> +  such the QEMU deployment on the host should account for the
> +  possibility of large memory peaks and apply countermeasures to
> +  provide continuity of host operations. It is typical for the Linux
> +  OOM killer to reap the process triggering host memory overcommit
> +  in the case of exccessive usage, offering a degree of protection.
> +  As such, bugs which can lead to excessive/unbounded memory allocations
> +  will usually not be classified as security flaws, but should be
> +  fixed as hardening bugs.


however, this is treated as denial of service, see **assert** /
**abort** above: if the excessive/unbounded memory allocations can be
triggered by an unpriveledged guest application, this can be considered
a security flaw.

> +* **degraded guest behaviour**. There are a set of bugs which can
> +  lead guest hardware devices to misbehave. For example, a flawed
> +  virtual IOMMU operation may not offer the guest device isolation
> +  that would otherwise be expected. If a guest triggered exploit
> +  requires kernel privileges (or root account access), and leads
> +  to sub-optimal behaviour of the virtual device this is considered
> +  a self inflicted service degradation. These will **not** be
> +  treated as security flaws, at most hardening bugs. If triggering
> +  the code path can be done by an unprivileged guest OS account,
> +  this may justify handling as a security bug.
> +
> +* **nested virtualization**. The scope for nested virtualization
> +  is to prevent a level 2 guest from breaking out into a level
> +  1 guest. As noted above, a number of scenarios exclude security
> +  handling for flaws only exploitable by the guest kernel / root
> +  account with affect the guest's own service/availability. In the
> +  context of nested virtualization with PCI device assignment, it
> +  may may be possible for a level 2 guest kernel to trigger flaws
> +  that affect the level 0 QEMU process. While these bugs should be
> +  fixed, they will not be triaged as security flaws at this time.
> +
> +* **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
> +  of CVEs. They will be fixed as routine bugs when time allows.
> +
>  Architecture
>  ------------
>  
> -- 
> 2.55.0

Re: [PULL 4/4] docs: outline some guidelines for security classification

[Michael S. Tsirkin]

On Tue, Jul 07, 2026 at 06:50:27PM +0100, Daniel P. Berrangé wrote:
> Beyond the overall virt/non-virt use case classification, there are
> a number of scenarios which we have decided will not be treated as
> security issues. Start to document some of these to give consistency
> in our treatment of incoming disclosures.
> 
> Reviewed-by: Thomas Huth <thuth@redhat.com>
> Reviewed-by: Cédric Le Goater <clg@redhat.com>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: Mauro Matteo Cascella <mcascell@redhat.com>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  docs/system/security.rst | 63 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 63 insertions(+)
> 
> diff --git a/docs/system/security.rst b/docs/system/security.rst
> index 53992048e6..52bbf0cc7a 100644
> --- a/docs/system/security.rst
> +++ b/docs/system/security.rst
> @@ -75,6 +75,69 @@ Bugs affecting the non-virtualization use case are not considered security
>  bugs at this time.  Users with non-virtualization use cases must not rely on
>  QEMU to provide guest isolation or any security guarantees.
>  
> +Security boundary scope
> +'''''''''''''''''''''''
> +
> +Even where a flaw affects the virtualization use case described above,
> +not all scenarios will be considered in scope. The following guidelines
> +are used to evaluate whether to apply the full security process, or treat
> +an issue as a normal bug.
> +
> +* **assert** / **abort**. If triggering the code path requires kernel
> +  privileges (or root account access) in the guest, asserts/aborts in
> +  QEMU are a self inflicted denial of service. These will **not** be
> +  treated as security flaws, at most hardening bugs. If triggering the
> +  code path can be done by an unprivileged guest OS account, this
> +  **may** justify handling as a security bug.
> +
> +* **vhost-user/vfio-user backends**. The backend processes have
> +  shared memory regions co-mapped with the QEMU process. The intent
> +  of the process separation is operational resilience & flexibility
> +  and allowing for independent software suppliers. There is not
> +  considered to be security boundary between QEMU and the vhost-user
> +  & vfio-user backends. Thus flaws in the backends which can cause
> +  crashes / undesirable behaviour in QEMU will **not** be treated as
> +  security flaws, but should be fixed as hardening bugs.
> +
> +* **memory allocation bounds**. There are many ways in which a QEMU
> +  process can legitimately consume an amount of memory that is
> +  significantly larger than the assigned guest RAM. QEMU's worst
> +  case memory usage should be considered effectively unbounded. As
> +  such the QEMU deployment on the host should account for the
> +  possibility of large memory peaks and apply countermeasures to
> +  provide continuity of host operations. It is typical for the Linux
> +  OOM killer to reap the process triggering host memory overcommit
> +  in the case of exccessive usage, offering a degree of protection.

It seems to work kinda unreliably here on my laptop. Likes killing firefox
for some reason. Using libvirt ... what am I doing wrong?

> +  As such, bugs which can lead to excessive/unbounded memory allocations
> +  will usually not be classified as security flaws, but should be
> +  fixed as hardening bugs.

Re: [PULL 0/4] Misc patches queues

[Daniel P. Berrangé]

Note, I have updated my PGP key with a new signing sub-key,
so it will need refreshing from keys.opengpg.org, under
the same primary key ID as you already have for me.

On Tue, Jul 07, 2026 at 06:50:23PM +0100, Daniel P. Berrangé wrote:
> The following changes since commit 94826ec1370328375c3b6d1e80fdc94c8f46c348:
> 
>   Merge tag 'accel-20260706' of https://github.com/philmd/qemu into staging (2026-07-06 18:38:14 +0200)
> 
> are available in the Git repository at:
> 
>   https://gitlab.com/berrange/qemu tags/misc-next-pull-request
> 
> for you to fetch changes up to 64d0d2efdd2822c827aa7cd276e15c7cefaccb95:
> 
>   docs: outline some guidelines for security classification (2026-07-07 18:36:15 +0100)
> 
> ----------------------------------------------------------------
> * Outline security classification guidelines
> * Use QEMU lock guards in inotify code
> * Fix certificate error checking
> 
> ----------------------------------------------------------------
> 
> Daniel P. Berrangé (1):
>   docs: outline some guidelines for security classification
> 
> Evgeny Kolmakov (1):
>   util/filemonitor-inotify: Use QEMU_LOCK_GUARD()
> 
> Peter Maydell (1):
>   io/channel-socket: Document why we can ignore socket_set_cork() errors
> 
> yujun (1):
>   crypto/x509-utils: fix gnutls error code in crt_init failure path
> 
>  crypto/x509-utils.c        |  3 +-
>  docs/system/security.rst   | 63 ++++++++++++++++++++++++++++++++++++++
>  io/channel-socket.c        |  6 ++++
>  util/filemonitor-inotify.c | 28 +++++------------
>  4 files changed, 79 insertions(+), 21 deletions(-)
> 
> -- 
> 2.55.0
> 

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 :|