Xen Security Advisory 531 v1 (CVE-2026-99286) - Linux xen-netback: guest can trigger use-after-free for network statistics reads
Subsystems (2)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2026-99286 / XSA-531
Linux xen-netback: guest can trigger use-after-free for network statistics reads
ISSUE DESCRIPTION
=================
The network statistic data in the driver is protected by RCU. Unfortunately when tearing down the queues after an error during connecting to the frontend (e.g. due to illegal Xenstore data filled in by the guest), there was missing RCU synchronization before freeing the memory holding the statistic data. This was meant to be fixed by the patch of XSA-526, but that patch failed to set the indication that the data should no longer be accessed, before waiting for RCU to have finished accesses. In case the data is being read via sysfs in this phase, access to already freed memory or memory being in new use is possible.
IMPACT
======
The most likely outcome is a driver crash, possibly escalated to a host crash. This then is a Denial of Service (DoS) affecting the entire host.
Information leaks cannot be ruled out.
VULNERABLE SYSTEMS
==================
Linux versions 4.11 and newer are vulnerable. Note that the patch for XSA-526 is still needed.
MITIGATION
==========
Using a userspace PV network backend (e.g. the qemu based "qnic" backend) will mitigate the problem.
Using a dedicated network driver domain per guest will mitigate the problem.
CREDITS
=======
This issue was discovered by Tu Dinh of Vates.
RESOLUTION
==========
Applying the attached patch resolves this issue.
xsa531-linux.patch Linux
$ sha256sum xsa531* 1da1dc0543ad3b61698e6d9afc90720bb54f314b6fbc58ab83b8ee0b86fda086 xsa531-linux.patch $
NOTE REGARDING LACK OF EMBARGO
==============================
The issue is directly related to the recent XSA-526 fix and easy to find. -----BEGIN PGP SIGNATURE-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmrzZgUMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZLHgH/i0+e6pRQkH5mI9w/GPnPDy/QGSVjEaLqj72Oo/9 NOi1fEwHibm7JPOO/NpZHDcGvh2Y5PT7DRlVw1+1EV2+lbLzbxHX2BWVySQx9cPk jBKem0k1udcCsKGxe09/wPW53NPmfw3KARs9L1KEJZl5/akXTUX3ZjSIOyoRg9oE nCmbgcfg2m+KfFGnrieQaiiMOO2iD2KZmeJFLsGaT007wVkeFx2vJBxEdTayiMvF A6BwRTc8gBd3iLxgBMO7Wdz5h3uWlgjDYq8E52tzMFbII3OeYCiiyStYlYFMk3la sVr8bYFcctn1xm4/XukqoS00EVcNVYqaQl1yxkDf8im9qZs=
=KIyG
-----END PGP SIGNATURE-----
From: Tu Dinh <[email protected]>
xen-netback: Fix XenBus connection failure cleanup
xenvif_get_stats and xenvif_get_ethtool_stats capture vif->num_queues under rcu_read_lock. We need to unpublish vif->num_queues before synchronize_net to ensure that readers that come afterwards will not read a non-zero vif->num_queues and attempt to access invalid queues.
This is the same cleanup algorithm as used in backend_disconnect and added in commit b17075d5c198 ("xen-netback: fix race condition on XenBus disconnect").
This is XSA-531
--- drivers/net/xen-netback/xenbus.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/net/xen-netback/xenbus.c +5 -3
@@ -731,6 +731,7 @@ static void connect(struct backend_info *be)unsigned int queue_index;unsigned int requested_num_queues;struct xenvif_queue *queue; +unsigned int num_queues;/* Check whether the frontend requested multiple queues * and read the number requested.
@@ -837,14 +838,15 @@ static void connect(struct backend_info *be)return ; err: -if (be->vif->num_queues >0 ) + num_queues = be->vif->num_queues; +if (num_queues >0 )xenvif_disconnect_data (be->vif);/* Clean up existing queues */ + be->vif->num_queues =0 ;synchronize_net (); -for (queue_index =0 ; queue_index < be->vif->num_queues; ++queue_index) +for (queue_index =0 ; queue_index < num_queues; ++queue_index)xenvif_deinit_queue (&be->vif->queues[queue_index]);vfree (be->vif->queues); be->vif->queues =NULL ; - be->vif->num_queues =0 ;xenvif_disconnect_ctrl (be->vif);return ; }
Signature · 1 line
2.56.0