CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46843 – scsi: ufs: core: Remove SCSI host only if added
https://notcve.org/view.php?id=CVE-2024-46843
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Remove SCSI host only if added If host tries to remove ufshcd driver from a UFS device it would cause a kernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before adding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host has been defered after MCQ configuration introduced by commit 0cab4023ec7b ("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported"). To guarantee that SCSI host is removed only if it has been added, set the scsi_host_added flag to true after adding a SCSI host and check whether it is set or not before removing it. • https://git.kernel.org/stable/c/2f49e05d6b58d660f035a75ff96b77071b4bd5ed https://git.kernel.org/stable/c/3844586e9bd9845140e1078f1e61896b576ac536 https://git.kernel.org/stable/c/7cbff570dbe8907e23bba06f6414899a0fbb2fcc •
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. The issue is that for MBX_TIMEOUT cases, when firmware returns SFP information at a later time, that same mailbox memory region references previously freed memory in its cmpl routine. Fix by adding checks for the MBX_TIMEOUT return code. During mailbox resource cleanup, check the mbox flag to make sure that the wait did not timeout. If the MBOX_WAKE flag is not set, then do not free the resources because it will be freed when firmware completes the mailbox at a later time in its cmpl routine. Also, increase the timeout from 30 to 60 seconds to accommodate boot scripts requiring longer timeouts. • 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. In walk_down_proc we also BUG_ON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In do_walk_down() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information. • 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 •