ghsa-vvc7-qvmv-vpjw
Vulnerability from github
Published
2024-05-20 12:30
Modified
2024-05-20 12:30
Details

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.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-35981"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-20T10:15:12Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: Do not send RSS key if it is not supported\n\nThere is a bug when setting the RSS options in virtio_net that can break\nthe whole machine, getting the kernel into an infinite loop.\n\nRunning the following command in any QEMU virtual machine with virtionet\nwill reproduce this problem:\n\n    # ethtool -X eth0  hfunc toeplitz\n\nThis is how the problem happens:\n\n1) ethtool_set_rxfh() calls virtnet_set_rxfh()\n\n2) virtnet_set_rxfh() calls virtnet_commit_rss_command()\n\n3) virtnet_commit_rss_command() populates 4 entries for the rss\nscatter-gather\n\n4) Since the command above does not have a key, then the last\nscatter-gatter entry will be zeroed, since rss_key_size == 0.\nsg_buf_size = vi-\u003erss_key_size;\n\n5) This buffer is passed to qemu, but qemu is not happy with a buffer\nwith zero length, and do the following in virtqueue_map_desc() (QEMU\nfunction):\n\n  if (!sz) {\n      virtio_error(vdev, \"virtio: zero sized buffers are not allowed\");\n\n6) virtio_error() (also QEMU function) set the device as broken\n\n    vdev-\u003ebroken = true;\n\n7) Qemu bails out, and do not repond this crazy kernel.\n\n8) The kernel is waiting for the response to come back (function\nvirtnet_send_command())\n\n9) The kernel is waiting doing the following :\n\n      while (!virtqueue_get_buf(vi-\u003ecvq, \u0026tmp) \u0026\u0026\n\t     !virtqueue_is_broken(vi-\u003ecvq))\n\t      cpu_relax();\n\n10) None of the following functions above is true, thus, the kernel\nloops here forever. Keeping in mind that virtqueue_is_broken() does\nnot look at the qemu `vdev-\u003ebroken`, so, it never realizes that the\nvitio is broken at QEMU side.\n\nFix it by not sending RSS commands if the feature is not available in\nthe device.",
  "id": "GHSA-vvc7-qvmv-vpjw",
  "modified": "2024-05-20T12:30:29Z",
  "published": "2024-05-20T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35981"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/059a49aa2e25c58f90b50151f109dd3c4cdb3a47"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/28e9a64638cd16bc1ecac9ff74ffeacb9fb652de"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/43a71c1b4b3a6d4db857b1435d271540279fc7de"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/539a2b995a4ed93125cb0efae0f793b00ab2158b"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.