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: 5.8EPSS: 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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42128 – leds: an30259a: Use devm_mutex_init() for mutex initialization
https://notcve.org/view.php?id=CVE-2024-42128
In the Linux kernel, the following vulnerability has been resolved: leds: an30259a: 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/3ead19aa341de89a8c3d88a091d8093ebea622e8 https://git.kernel.org/stable/c/9dba44460bfca657ca43f03ea9bafa4f9f7dd077 https://git.kernel.org/stable/c/c382e2e3eccb6b7ca8c7aff5092c1668428e7de6 •