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: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42133 – Bluetooth: Ignore too large handle values in BIG
https://notcve.org/view.php?id=CVE-2024-42133
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Ignore too large handle values in BIG hci_le_big_sync_established_evt is necessary to filter out cases where the handle value is belonging to ida id range, otherwise ida will be erroneously released in hci_conn_cleanup. • 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/38263088b845abeeeb98dda5b87c0de3063b6dbb https://git.kernel.org/stable/c/dad0003ccc68457baf005a6ed75b4d321463fe3d https://git.kernel.org/stable/c/015d79c96d62cd8a4a359fcf5be40d58088c936b •
CVSS: -EPSS: 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 •
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 •