CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35983 – bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS
https://notcve.org/view.php?id=CVE-2024-35983
In the Linux kernel, the following vulnerability has been resolved: bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS bits_per() rounds up to the next power of two when passed a power of two. This causes crashes on some machines and configurations. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: límites: utilice el número correcto de bits para potencia de dos CONFIG_NR_CPUS bits_per() redondea a la siguiente potencia de dos cuando se pasa una potencia de dos. Esto provoca fallos en algunas máquinas y configuraciones. • https://git.kernel.org/stable/c/d6077e0d38b4953c863d0db4a5b3f41d21e0d546 https://git.kernel.org/stable/c/83a2275f9d3230c761014b1467888b1ef469be74 https://git.kernel.org/stable/c/d2a7a81088c6abe778b0a93a7eeb79487a943818 https://git.kernel.org/stable/c/428ca0000f0abd5c99354c52a36becf2b815ca21 https://git.kernel.org/stable/c/b46c822f8b555b9513df44047b0e72c06720df62 https://git.kernel.org/stable/c/cf778fff03be1ee88c49b72959650147573c3301 https://git.kernel.org/stable/c/b2e1b090a590d41abe647eadb6bf2a5dc47b63ab https://git.kernel.org/stable/c/d34a516f2635090d36a306f84573e8de3 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35982 – batman-adv: Avoid infinite loop trying to resize local TT
https://notcve.org/view.php?id=CVE-2024-35982
In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid infinite loop trying to resize local TT If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet. But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110) in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more. There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. • https://git.kernel.org/stable/c/a19d3d85e1b854e4a483a55d740a42458085560d https://git.kernel.org/stable/c/5eaeaa72113865661568002bb57d611492451d3e https://git.kernel.org/stable/c/04720ea2e6c64459a90ca28570ea78335eccd924 https://git.kernel.org/stable/c/b3ddf6904073990492454b1dd1c10a24be8c74c6 https://git.kernel.org/stable/c/70a8be9dc2fb65d67f8c1e0c88c587e08e2e575d https://git.kernel.org/stable/c/87b6af1a7683e021710c08fc0551fc078346032f https://git.kernel.org/stable/c/3fe79b2c83461edbbf86ed8a6f3924820ff89259 https://git.kernel.org/stable/c/4ca2a5fb54ea2cc43edea614207fcede5 • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35981 – virtio_net: Do not send RSS key if it is not supported
https://notcve.org/view.php?id=CVE-2024-35981
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. • https://git.kernel.org/stable/c/c7114b1249fa3b5f3a434606ba4cc89c4a27d618 https://git.kernel.org/stable/c/539a2b995a4ed93125cb0efae0f793b00ab2158b https://git.kernel.org/stable/c/43a71c1b4b3a6d4db857b1435d271540279fc7de https://git.kernel.org/stable/c/28e9a64638cd16bc1ecac9ff74ffeacb9fb652de https://git.kernel.org/stable/c/059a49aa2e25c58f90b50151f109dd3c4cdb3a47 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35978 – Bluetooth: Fix memory leak in hci_req_sync_complete()
https://notcve.org/view.php?id=CVE-2024-35978
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix memory leak in hci_req_sync_complete() In 'hci_req_sync_complete()', always free the previous sync request state before assigning reference to a new one. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: corrija la pérdida de memoria en hci_req_sync_complete() En 'hci_req_sync_complete()', libere siempre el estado de solicitud de sincronización anterior antes de asignar una referencia a una nueva. • https://git.kernel.org/stable/c/f60cb30579d3401cab1ed36b42df5c0568ae0ba7 https://git.kernel.org/stable/c/89a32741f4217856066c198a4a7267bcdd1edd67 https://git.kernel.org/stable/c/4beab84fbb50df3be1d8f8a976e6fe882ca65cb2 https://git.kernel.org/stable/c/8478394f76c748862ef179a16f651f752bdafaf0 https://git.kernel.org/stable/c/75193678cce993aa959e7764b6df2f599886dd06 https://git.kernel.org/stable/c/66fab1e120b39f8f47a94186ddee36006fc02ca8 https://git.kernel.org/stable/c/9ab5e44b9bac946bd49fd63264a08cd1ea494e76 https://git.kernel.org/stable/c/e4cb8382fff6706436b66eafd9c0ee857 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35977 – platform/chrome: cros_ec_uart: properly fix race condition
https://notcve.org/view.php?id=CVE-2024-35977
In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_uart: properly fix race condition The cros_ec_uart_probe() function calls devm_serdev_device_open() before it calls serdev_device_set_client_ops(). This can trigger a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> ... ? ttyport_receive_buf A simplified version of crashing code is as follows: static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) { struct serdev_device *serdev = ctrl->serdev; if (!serdev || !serdev->ops->receive_buf) // CRASH! • https://git.kernel.org/stable/c/01f95d42b8f4e88f20d68791b0a85dbb9e3d1ac9 https://git.kernel.org/stable/c/cfd758041d8b79aa8c3f811b6bd6105379f2f702 https://git.kernel.org/stable/c/9e9bb74a93b7daa32313ccaefd0edc529d40daf8 https://git.kernel.org/stable/c/5e700b384ec13f5bcac9855cb28fcc674f1d3593 •