CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46842 – scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info
https://notcve.org/view.php?id=CVE-2024-46842
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info The MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the routine unconditionally frees submitted mailbox commands regardless of return status. • https://git.kernel.org/stable/c/bba47fe3b038cca3d3ebd799665ce69d6d273b58 https://git.kernel.org/stable/c/ede596b1434b57c0b3fd5c02b326efe5c54f6e48 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46841 – btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()
https://notcve.org/view.php?id=CVE-2024-46841
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc() We handle errors here properly, ENOMEM isn't fatal, return the error. • https://git.kernel.org/stable/c/704c359b4093a2af650a20eaa030c435d7c30f91 https://git.kernel.org/stable/c/a580fb2c3479d993556e1c31b237c9e5be4944a3 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46840 – btrfs: clean up our handling of refs == 0 in snapshot delete
https://notcve.org/view.php?id=CVE-2024-46840
In the Linux kernel, the following vulnerability has been resolved: btrfs: clean up our handling of refs == 0 in snapshot delete In reada we BUG_ON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. • https://git.kernel.org/stable/c/c847b28a799733b04574060ab9d00f215970627d https://git.kernel.org/stable/c/71291aa7246645ef622621934d2067400380645e https://git.kernel.org/stable/c/c60676b81fab456b672796830f6d8057058f029c https://git.kernel.org/stable/c/728d4d045b628e006b48a448f3326a7194c88d32 https://git.kernel.org/stable/c/9cc887ac24b7a0598f4042ae9af6b9a33072f75b https://git.kernel.org/stable/c/7d1df13bf078ffebfedd361d714ff6cee1ff01b9 https://git.kernel.org/stable/c/03804641ec2d0da4fa088ad21c88e703d151ce16 https://git.kernel.org/stable/c/b8ccef048354074a548f108e51d0557d6 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46838 – userfaultfd: don't BUG_ON() if khugepaged yanks our page table
https://notcve.org/view.php?id=CVE-2024-46838
In the Linux kernel, the following vulnerability has been resolved: userfaultfd: don't BUG_ON() if khugepaged yanks our page table Since khugepaged was changed to allow retracting page tables in file mappings without holding the mmap lock, these BUG_ON()s are wrong - get rid of them. We could also remove the preceding "if (unlikely(...))" block, but then we could reach pte_offset_map_lock() with transhuge pages not just for file mappings but also for anonymous mappings - which would probably be fine but I think is not necessarily expected. • https://git.kernel.org/stable/c/1d65b771bc08cd054cf6d3766a72e113dc46d62f https://git.kernel.org/stable/c/4a594acc12d5954cdc71d4450a386748bf3d136a https://git.kernel.org/stable/c/db978287e908d48b209e374b00d847b2d785e0a9 https://git.kernel.org/stable/c/4828d207dc5161dc7ddf9a4f6dcfd80c7dd7d20a •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46837 – drm/panthor: Restrict high priorities on group_create
https://notcve.org/view.php?id=CVE-2024-46837
In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Restrict high priorities on group_create We were allowing any users to create a high priority group without any permission checks. • https://git.kernel.org/stable/c/de85488138247d034eb3241840424a54d660926b https://git.kernel.org/stable/c/33eb0344e186a2bcc257c6c5a6e65c1cb42adb4a https://git.kernel.org/stable/c/5f7762042f8a5377bd8a32844db353c0311a7369 •