CVE-2024-35981: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: virtio_net: Do not send RSS key if it is not supported There is a bug when setting the RSS options in virtio_net that can break the whole machine, getting the kernel into an infinite loop. Running the following command in any QEMU virtual machine with virtionet will reproduce this problem: # ethtool -X eth0 hfunc toeplitz This is how the problem happens: 1) ethtool_set_rxfh() calls virtnet_set_rxfh() 2) virtnet_set_rxfh() calls virtnet_commit_rss_command() 3) virtnet_commit_rss_command() populates 4 entries for the rss scatter-gather 4) Since the command above does not have a key, then the last scatter-gatter entry will be zeroed, since rss_key_size == 0. sg_buf_size = vi->rss_key_size; 5) This buffer is passed to qemu, but qemu is not happy with a buffer with zero length, and do the following in virtqueue_map_desc() (QEMU function): if (!sz) { virtio_error(vdev, "virtio: zero sized buffers are not allowed"); 6) virtio_error() (also QEMU function) set the device as broken vdev->broken = true; 7) Qemu bails out, and do not repond this crazy kernel. 8) The kernel is waiting for the response to come back (function virtnet_send_command()) 9) The kernel is waiting doing the following : while (!virtqueue_get_buf(vi->cvq, &tmp) && !virtqueue_is_broken(vi->cvq)) cpu_relax(); 10) None of the following functions above is true, thus, the kernel loops here forever. Keeping in mind that virtqueue_is_broken() does not look at the qemu `vdev->broken`, so, it never realizes that the vitio is broken at QEMU side. Fix it by not sending RSS commands if the feature is not available in the device.
AI Analysis
Technical Summary
CVE-2024-35981 is a vulnerability in the Linux kernel's virtio_net driver, specifically related to the handling of Receive Side Scaling (RSS) options in virtualized environments using QEMU with virtio network devices. The issue arises when an RSS key is not supported by the device but the kernel attempts to set RSS options regardless. When the command to set the RSS hash function (e.g., using `ethtool -X eth0 hfunc toeplitz`) is issued inside a QEMU virtual machine with a virtio_net interface, the kernel calls a sequence of functions culminating in virtnet_commit_rss_command(). This function prepares a scatter-gather buffer for the RSS command, but if the RSS key size is zero (indicating the feature is unsupported), the last scatter-gather entry is zeroed out, resulting in a zero-length buffer being passed to QEMU. QEMU's virtqueue_map_desc() function rejects zero-sized buffers, marking the device as broken (`vdev->broken = true`) and ceasing to respond to the kernel. However, the kernel's virtio driver does not check QEMU's broken device flag and waits indefinitely for a response that never arrives, entering an infinite loop. This effectively causes the entire virtual machine to hang or become unresponsive. The vulnerability is fixed by ensuring that RSS commands are not sent if the device does not support the feature, preventing the zero-length buffer scenario and the subsequent infinite loop. This is a denial-of-service (DoS) vulnerability affecting Linux kernels running as guests in QEMU virtual machines using virtio_net devices when RSS is misconfigured or unsupported.
Potential Impact
For European organizations relying on Linux-based virtual machines running under QEMU with virtio_net network interfaces, this vulnerability can lead to complete VM hangs or crashes when RSS settings are manipulated or misconfigured. This can disrupt critical services hosted in virtualized environments, including cloud infrastructure, private data centers, and development/testing platforms. The infinite loop in the kernel can cause resource exhaustion and require manual intervention to recover the VM, leading to downtime and potential loss of availability for business-critical applications. Since the issue is triggered by a specific ethtool command, it could be exploited by a malicious insider or an attacker with guest VM access to cause denial of service. This is particularly impactful for European organizations with large-scale virtualization deployments in sectors such as finance, telecommunications, and government, where uptime and service continuity are paramount. Additionally, the vulnerability may complicate automated network configuration management and monitoring tools that use ethtool to adjust RSS settings, potentially causing unintended outages.
Mitigation Recommendations
1. Apply Linux kernel patches or updates that address CVE-2024-35981 as soon as they become available from trusted Linux distributions or kernel maintainers. 2. Avoid sending RSS configuration commands (e.g., via ethtool) to virtio_net devices in QEMU guests unless the feature is explicitly supported by the device. 3. Implement strict access controls and monitoring on guest VMs to prevent unauthorized users from executing commands that modify network device settings. 4. In environments where patching is delayed, consider disabling RSS configuration changes or restricting ethtool usage within VMs to trusted administrators only. 5. Monitor VM logs and QEMU device states for signs of virtio device failures or hangs, enabling rapid detection and recovery. 6. Test network configuration management tools in isolated environments to ensure they do not inadvertently trigger this issue. 7. Coordinate with virtualization platform vendors to ensure hypervisor and guest tools are updated to handle virtio device feature negotiation correctly.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Denmark, Ireland, Belgium, Italy
CVE-2024-35981: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: virtio_net: Do not send RSS key if it is not supported There is a bug when setting the RSS options in virtio_net that can break the whole machine, getting the kernel into an infinite loop. Running the following command in any QEMU virtual machine with virtionet will reproduce this problem: # ethtool -X eth0 hfunc toeplitz This is how the problem happens: 1) ethtool_set_rxfh() calls virtnet_set_rxfh() 2) virtnet_set_rxfh() calls virtnet_commit_rss_command() 3) virtnet_commit_rss_command() populates 4 entries for the rss scatter-gather 4) Since the command above does not have a key, then the last scatter-gatter entry will be zeroed, since rss_key_size == 0. sg_buf_size = vi->rss_key_size; 5) This buffer is passed to qemu, but qemu is not happy with a buffer with zero length, and do the following in virtqueue_map_desc() (QEMU function): if (!sz) { virtio_error(vdev, "virtio: zero sized buffers are not allowed"); 6) virtio_error() (also QEMU function) set the device as broken vdev->broken = true; 7) Qemu bails out, and do not repond this crazy kernel. 8) The kernel is waiting for the response to come back (function virtnet_send_command()) 9) The kernel is waiting doing the following : while (!virtqueue_get_buf(vi->cvq, &tmp) && !virtqueue_is_broken(vi->cvq)) cpu_relax(); 10) None of the following functions above is true, thus, the kernel loops here forever. Keeping in mind that virtqueue_is_broken() does not look at the qemu `vdev->broken`, so, it never realizes that the vitio is broken at QEMU side. Fix it by not sending RSS commands if the feature is not available in the device.
AI-Powered Analysis
Technical Analysis
CVE-2024-35981 is a vulnerability in the Linux kernel's virtio_net driver, specifically related to the handling of Receive Side Scaling (RSS) options in virtualized environments using QEMU with virtio network devices. The issue arises when an RSS key is not supported by the device but the kernel attempts to set RSS options regardless. When the command to set the RSS hash function (e.g., using `ethtool -X eth0 hfunc toeplitz`) is issued inside a QEMU virtual machine with a virtio_net interface, the kernel calls a sequence of functions culminating in virtnet_commit_rss_command(). This function prepares a scatter-gather buffer for the RSS command, but if the RSS key size is zero (indicating the feature is unsupported), the last scatter-gather entry is zeroed out, resulting in a zero-length buffer being passed to QEMU. QEMU's virtqueue_map_desc() function rejects zero-sized buffers, marking the device as broken (`vdev->broken = true`) and ceasing to respond to the kernel. However, the kernel's virtio driver does not check QEMU's broken device flag and waits indefinitely for a response that never arrives, entering an infinite loop. This effectively causes the entire virtual machine to hang or become unresponsive. The vulnerability is fixed by ensuring that RSS commands are not sent if the device does not support the feature, preventing the zero-length buffer scenario and the subsequent infinite loop. This is a denial-of-service (DoS) vulnerability affecting Linux kernels running as guests in QEMU virtual machines using virtio_net devices when RSS is misconfigured or unsupported.
Potential Impact
For European organizations relying on Linux-based virtual machines running under QEMU with virtio_net network interfaces, this vulnerability can lead to complete VM hangs or crashes when RSS settings are manipulated or misconfigured. This can disrupt critical services hosted in virtualized environments, including cloud infrastructure, private data centers, and development/testing platforms. The infinite loop in the kernel can cause resource exhaustion and require manual intervention to recover the VM, leading to downtime and potential loss of availability for business-critical applications. Since the issue is triggered by a specific ethtool command, it could be exploited by a malicious insider or an attacker with guest VM access to cause denial of service. This is particularly impactful for European organizations with large-scale virtualization deployments in sectors such as finance, telecommunications, and government, where uptime and service continuity are paramount. Additionally, the vulnerability may complicate automated network configuration management and monitoring tools that use ethtool to adjust RSS settings, potentially causing unintended outages.
Mitigation Recommendations
1. Apply Linux kernel patches or updates that address CVE-2024-35981 as soon as they become available from trusted Linux distributions or kernel maintainers. 2. Avoid sending RSS configuration commands (e.g., via ethtool) to virtio_net devices in QEMU guests unless the feature is explicitly supported by the device. 3. Implement strict access controls and monitoring on guest VMs to prevent unauthorized users from executing commands that modify network device settings. 4. In environments where patching is delayed, consider disabling RSS configuration changes or restricting ethtool usage within VMs to trusted administrators only. 5. Monitor VM logs and QEMU device states for signs of virtio device failures or hangs, enabling rapid detection and recovery. 6. Test network configuration management tools in isolated environments to ensure they do not inadvertently trigger this issue. 7. Coordinate with virtualization platform vendors to ensure hypervisor and guest tools are updated to handle virtio device feature negotiation correctly.
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-05-17T13:50:33.144Z
- Cisa Enriched
- true
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9828c4522896dcbe2370
Added to database: 5/21/2025, 9:08:56 AM
Last enriched: 6/29/2025, 8:55:58 AM
Last updated: 8/5/2025, 6:36:55 PM
Views: 12
Related Threats
CVE-2025-8285: CWE-862: Missing Authorization in Mattermost Mattermost Confluence Plugin
MediumCVE-2025-54525: CWE-1287: Improper Validation of Specified Type of Input in Mattermost Mattermost Confluence Plugin
HighCVE-2025-54478: CWE-306: Missing Authentication for Critical Function in Mattermost Mattermost Confluence Plugin
HighCVE-2025-54463: CWE-754: Improper Check for Unusual or Exceptional Conditions in Mattermost Mattermost Confluence Plugin
MediumCVE-2025-54458: CWE-862: Missing Authorization in Mattermost Mattermost Confluence Plugin
MediumActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.