Описание
In the Linux kernel, the following vulnerability has been resolved:
xen-netback: reject zero-queue configuration from guest
A malicious or buggy Xen guest can write "0" to the xenbus key "multi-queue-num-queues". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range().
On systems with panic_on_warn=1, this allows a guest-to-host denial of service.
The Xen network interface specification requires the queue count to be "greater than zero".
Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added.
In the Linux kernel, the following vulnerability has been resolved:
xen-netback: reject zero-queue configuration from guest
A malicious or buggy Xen guest can write "0" to the xenbus key "multi-queue-num-queues". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range().
On systems with panic_on_warn=1, this allows a guest-to-host denial of service.
The Xen network interface specification requires the queue count to be "greater than zero".
Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added.
Ссылки
- https://nvd.nist.gov/vuln/detail/CVE-2026-45890
- https://git.kernel.org/stable/c/2993e0f904c45f8af12917344bb1cac7ccd05a60
- https://git.kernel.org/stable/c/654780dee9eae419e1648ea58462c4efe54518fa
- https://git.kernel.org/stable/c/6d1dc8014334c7fb25719999bca84d811e60a559
- https://git.kernel.org/stable/c/787bfa423228c4b02ba3368128f625d579085353
- https://git.kernel.org/stable/c/88b0fced1bbbfdb356a007592604008ffc93a6a1
- https://git.kernel.org/stable/c/ce66d6786de45b7ed9cbbdc0988054bf09e58f54
- https://git.kernel.org/stable/c/d99f69ddc70fd9f4b8148add62209a1a8eb5c615
- https://git.kernel.org/stable/c/ec4859ac5c933e3315543a61adc1ca4358006a41
EPSS
CVE ID
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: xen-netback: reject zero-queue configuration from guest A malicious or buggy Xen guest can write "0" to the xenbus key "multi-queue-num-queues". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range(). On systems with panic_on_warn=1, this allows a guest-to-host denial of service. The Xen network interface specification requires the queue count to be "greater than zero". Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added.
In the Linux kernel, the following vulnerability has been resolved: xen-netback: reject zero-queue configuration from guest A malicious or buggy Xen guest can write "0" to the xenbus key "multi-queue-num-queues". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range(). On systems with panic_on_warn=1, this allows a guest-to-host denial of service. The Xen network interface specification requires the queue count to be "greater than zero". Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added.
In the Linux kernel, the following vulnerability has been resolved: xen-netback: reject zero-queue configuration from guest A malicious or buggy Xen guest can write "0" to the xenbus key "multi-queue-num-queues". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range(). On systems with panic_on_warn=1, this allows a guest-to-host denial of service. The Xen network interface specification requires the queue count to be "greater than zero". Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added.
In the Linux kernel, the following vulnerability has been resolved: x ...
EPSS