CVE-2024-35981

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_net: no enviar clave RSS si no es compatible. Hay un error al configurar las opciones de RSS en virtio_net que puede dañar toda la máquina, haciendo que el kernel entre en un bucle infinito. Ejecutar el siguiente comando en cualquier máquina virtual QEMU con virtionet reproducirá este problema: # ethtool -X eth0 hfunc toeplitz Así es como ocurre el problema: 1) ethtool_set_rxfh() llama a virtnet_set_rxfh() 2) virtnet_set_rxfh() llama a virtnet_commit_rss_command() 3) virtnet_commit_rss_command() completa 4 entradas para rss scatter-gather 4) Dado que el comando anterior no tiene una clave, la última entrada de scatter-gatter se pondrá a cero, ya que rss_key_size == 0. sg_buf_size = vi->rss_key_size; 5) Este búfer se pasa a qemu, pero qemu no está contento con un búfer con longitud cero, y haga lo siguiente en virtqueue_map_desc() (función QEMU): if (!sz) { virtio_error(vdev, "virtio: buffers de tamaño cero no están permitidos"); 6) virtio_error() (también función QEMU) configura el dispositivo como roto vdev->broken = true; 7) Qemu se retira y no responde a este kernel loco. 8) El kernel está esperando a que regrese la respuesta (función virtnet_send_command()) 9) El kernel está esperando haciendo lo siguiente: while (!virtqueue_get_buf(vi->cvq, &tmp) && !virtqueue_is_broken(vi->cvq)) cpu_relax(); 10) Ninguna de las siguientes funciones anteriores es verdadera, por lo tanto, el núcleo se repite aquí para siempre. Teniendo en cuenta que virtqueue_is_broken() no mira el qemu `vdev->broken`, por lo tanto, nunca se da cuenta de que el vitio está roto en el lado de QEMU. Solucionelo no enviando comandos RSS si la función no está disponible en el dispositivo.

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.

It was discovered that a race condition existed in the Bluetooth subsystem in the Linux kernel when modifying certain settings values through debugfs. A privileged local attacker could use this to cause a denial of service. Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system.