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: 4EXPL: 0CVE-2024-46836 – usb: gadget: aspeed_udc: validate endpoint index for ast udc
https://notcve.org/view.php?id=CVE-2024-46836
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed_udc: validate endpoint index for ast udc We should verify the bound of the array to assure that host may not manipulate the index to point past endpoint array. Found by static analysis. • https://git.kernel.org/stable/c/31bd4fab49c0adc6228848357c1b1df9395858af https://git.kernel.org/stable/c/b2a50ffdd1a079869a62198a8d1441355c513c7c https://git.kernel.org/stable/c/6fe9ca2ca389114c8da66e534c18273497843e8a https://git.kernel.org/stable/c/ee0d382feb44ec0f445e2ad63786cd7f3f6a8199 •