CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46844 – um: line: always fill *error_out in setup_one_line()
https://notcve.org/view.php?id=CVE-2024-46844
In the Linux kernel, the following vulnerability has been resolved: um: line: always fill *error_out in setup_one_line() The pointer isn't initialized by callers, but I have encountered cases where it's still printed; initialize it in all possible cases in setup_one_line(). • https://git.kernel.org/stable/c/3bedb7ce080690d0d6172db790790c1219bcbdd5 https://git.kernel.org/stable/c/96301fdc2d533a196197c055af875fe33d47ef84 https://git.kernel.org/stable/c/c8944d449fda9f58c03bd99649b2df09948fc874 https://git.kernel.org/stable/c/43f782c27907f306c664b6614fd6f264ac32cce6 https://git.kernel.org/stable/c/289979d64573f43df1d0e6bc6435de63a0d69cdf https://git.kernel.org/stable/c/ec5b47a370177d79ae7773858042c107e21f8ecc https://git.kernel.org/stable/c/fc843d3837ebcb1c16d3768ef3eb55e25d5331f2 https://git.kernel.org/stable/c/824ac4a5edd3f7494ab1996826c4f47f8 •
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 •