CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42132 – bluetooth/hci: disallow setting handle bigger than HCI_CONN_HANDLE_MAX
https://notcve.org/view.php?id=CVE-2024-42132
In the Linux kernel, the following vulnerability has been resolved: bluetooth/hci: disallow setting handle bigger than HCI_CONN_HANDLE_MAX Syzbot hit warning in hci_conn_del() caused by freeing handle that was not allocated using ida allocator. This is caused by handle bigger than HCI_CONN_HANDLE_MAX passed by hci_le_big_sync_established_evt(), which makes code think it's unset connection. Add same check for handle upper bound as in hci_conn_set_handle() to prevent warning. • https://git.kernel.org/stable/c/84cb0143fb8a03bf941c7aaedd56c938c99dafad https://git.kernel.org/stable/c/181a42edddf51d5d9697ecdf365d72ebeab5afb0 https://git.kernel.org/stable/c/e9f708beada55426c8d678e2f46af659eb5bf4f0 https://git.kernel.org/stable/c/4970e48f83dbd21d2a6a7cdaaafc2a71f7f45dc4 https://git.kernel.org/stable/c/d311036696fed778301d08a71a4bef737b86d8c5 https://git.kernel.org/stable/c/1cc18c2ab2e8c54c355ea7c0423a636e415a0c23 https://access.redhat.com/security/cve/CVE-2024-42132 https://bugzilla.redhat.com/show_bug.cgi?id=2301497 •
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: 3EXPL: 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/172ffd26a5af13e951d0e82df7cfc5a95b04fa80 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 •