Page 245 of 5977 results (0.009 seconds)

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

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: 0

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: 5.5EPSS: 0%CPEs: 4EXPL: 0

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: 0

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: 0

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 •