CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42135 – vhost_task: Handle SIGKILL by flushing work and exiting
https://notcve.org/view.php?id=CVE-2024-42135
In the Linux kernel, the following vulnerability has been resolved: vhost_task: Handle SIGKILL by flushing work and exiting Instead of lingering until the device is closed, this has us handle SIGKILL by: 1. marking the worker as killed so we no longer try to use it with new virtqueues and new flush operations. 2. setting the virtqueue to worker mapping so no new works are queued. 3. running all the exiting works. • https://git.kernel.org/stable/c/abe067dc3a662eef7d5cddbbc41ed50a0b68b0af https://git.kernel.org/stable/c/dec987fe2df670827eb53b97c9552ed8dfc63ad4 https://git.kernel.org/stable/c/db5247d9bf5c6ade9fd70b4e4897441e0269b233 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42134 – virtio-pci: Check if is_avq is NULL
https://notcve.org/view.php?id=CVE-2024-42134
In the Linux kernel, the following vulnerability has been resolved: virtio-pci: Check if is_avq is NULL [bug] In the virtio_pci_common.c function vp_del_vqs, vp_dev->is_avq is involved to determine whether it is admin virtqueue, but this function vp_dev->is_avq may be empty. For installations, virtio_pci_legacy does not assign a value to vp_dev->is_avq. [fix] Check whether it is vp_dev->is_avq before use. [test] Test with virsh Attach device Before this patch, the following command would crash the guest system After applying the patch, everything seems to be working fine. • https://git.kernel.org/stable/c/5e2024b0b9b3d5709e3f7e9b92951d7e29154106 https://git.kernel.org/stable/c/c8fae27d141a32a1624d0d0d5419d94252824498 •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42131 – mm: avoid overflows in dirty throttling logic
https://notcve.org/view.php?id=CVE-2024-42131
In the Linux kernel, the following vulnerability has been resolved: mm: avoid overflows in dirty throttling logic The dirty throttling logic is interspersed with assumptions that dirty limits in PAGE_SIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirty_bytes / dirty_background_bytes interfaces we can just refuse to set so large limits. For dirty_ratio / dirty_background_ratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. • https://git.kernel.org/stable/c/2b2d2b8766db028bd827af34075f221ae9e9efff https://git.kernel.org/stable/c/4d3817b64eda07491bdd86a234629fe0764fb42a https://git.kernel.org/stable/c/7a49389771ae7666f4dc3426e2a4594bf23ae290 https://git.kernel.org/stable/c/a25e8536184516b55ef89ab91dd2eea429de28d2 https://git.kernel.org/stable/c/c83ed422c24f0d4b264f89291d4fabe285f80dbc https://git.kernel.org/stable/c/bd16a7ee339aef3ee4c90cb23902afb6af379ea0 https://git.kernel.org/stable/c/8e0b5e7f2895eccef5c2a0018b589266f90c4805 https://git.kernel.org/stable/c/385d838df280eba6c8680f9777bfa0d0b • CWE-190: Integer Overflow or Wraparound •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42130 – nfc/nci: Add the inconsistency check between the input data length and count
https://notcve.org/view.php?id=CVE-2024-42130
In the Linux kernel, the following vulnerability has been resolved: nfc/nci: Add the inconsistency check between the input data length and count write$nci(r0, &(0x7f0000000740)=ANY=[@ANYBLOB="610501"], 0xf) Syzbot constructed a write() call with a data length of 3 bytes but a count value of 15, which passed too little data to meet the basic requirements of the function nci_rf_intf_activated_ntf_packet(). Therefore, increasing the comparison between data length and count value to avoid problems caused by inconsistent data length and count. • https://git.kernel.org/stable/c/f07bcd8bba803c9e6ad2048543185d6c56587a2f https://git.kernel.org/stable/c/41f5e2840cd0629f049ce5ce2f8dd10a8299de42 https://git.kernel.org/stable/c/056478b4321b36ca33567089d39ac992f6c9c37a https://git.kernel.org/stable/c/22a72c1c10f43ca645a98725e0faff34592f4d08 https://git.kernel.org/stable/c/068648aab72c9ba7b0597354ef4d81ffaac7b979 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42129 – leds: mlxreg: Use devm_mutex_init() for mutex initialization
https://notcve.org/view.php?id=CVE-2024-42129
In the Linux kernel, the following vulnerability has been resolved: leds: mlxreg: Use devm_mutex_init() for mutex initialization In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead. • https://git.kernel.org/stable/c/3b62888307ae44b68512d3f7735c26a4c8e45b51 https://git.kernel.org/stable/c/efc347b9efee1c2b081f5281d33be4559fa50a16 •