CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-45027 – usb: xhci: Check for xhci->interrupters being allocated in xhci_mem_clearup()
https://notcve.org/view.php?id=CVE-2024-45027
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Check for xhci->interrupters being allocated in xhci_mem_clearup() If xhci_mem_init() fails, it calls into xhci_mem_cleanup() to mop up the damage. • https://git.kernel.org/stable/c/c99b38c412343053e9af187e595793c8805bb9b8 https://git.kernel.org/stable/c/770cacc75b0091ece17349195d72133912c1ca7c https://git.kernel.org/stable/c/dcdb52d948f3a17ccd3fce757d9bd981d7c32039 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-45026 – s390/dasd: fix error recovery leading to data corruption on ESE devices
https://notcve.org/view.php?id=CVE-2024-45026
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix error recovery leading to data corruption on ESE devices Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing. The dasd_ese_needs_format function checks for error codes that signal the non existence of a proper track format. The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart. Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode. Also remove the check for file protected since this is not a valid ESE handling case. • https://git.kernel.org/stable/c/5e2b17e712cf10cc3cc98fde28a88e8f1a1267e9 https://git.kernel.org/stable/c/19f60a55b2fda49bc4f6134a5f6356ef62ee69d8 https://git.kernel.org/stable/c/e245a18281c252c8dbc467492e09bb5d4b012118 https://git.kernel.org/stable/c/a665e3b7ac7d5cdc26e00e3d0fc8fd490e00316a https://git.kernel.org/stable/c/0a228896a1b3654cd461ff654f6a64e97a9c3246 https://git.kernel.org/stable/c/93a7e2856951680cd7fe6ebd705ac10c8a8a5efd https://git.kernel.org/stable/c/5d4a304338daf83ace2887aaacafd66fe99ed5cc https://git.kernel.org/stable/c/7db4042336580dfd75cb5faa82c12cd51 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-45025 – fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE
https://notcve.org/view.php?id=CVE-2024-45025
In the Linux kernel, the following vulnerability has been resolved: fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE copy_fd_bitmaps(new, old, count) is expected to copy the first count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. • https://git.kernel.org/stable/c/ee501f827f3db02d4e599afbbc1a7f8b792d05d7 https://git.kernel.org/stable/c/e807487a1d5fd5d941f26578ae826ca815dbfcd6 https://git.kernel.org/stable/c/fe5bf14881701119aeeda7cf685f3c226c7380df https://git.kernel.org/stable/c/5053581fe5dfb09b58c65dd8462bf5dea71f41ff https://git.kernel.org/stable/c/8cad3b2b3ab81ca55f37405ffd1315bcc2948058 https://git.kernel.org/stable/c/dd72ae8b0fce9c0bbe9582b9b50820f0407f8d8a https://git.kernel.org/stable/c/c69d18f0ac7060de724511537810f10f29a27958 https://git.kernel.org/stable/c/9a2fa1472083580b6c66bdaf291f591e1 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-45024 – mm/hugetlb: fix hugetlb vs. core-mm PT locking
https://notcve.org/view.php?id=CVE-2024-45024
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb vs. core-mm PT locking We recently made GUP's common page table walking code to also walk hugetlb VMAs without most hugetlb special-casing, preparing for the future of having less hugetlb-specific page table walking code in the codebase. Turns out that we missed one page table locking detail: page table locking for hugetlb folios that are not mapped using a single PMD/PUD. Assume we have hugetlb folio that spans multiple PTEs (e.g., 64 KiB hugetlb folios on arm64 with 4 KiB base page size). • https://git.kernel.org/stable/c/9cb28da54643ad464c47585cd5866c30b0218e67 https://git.kernel.org/stable/c/7300dadba49e531af2d890ae4e34c9b115384a62 https://git.kernel.org/stable/c/5f75cfbd6bb02295ddaed48adf667b6c828ce07b •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-45023 – md/raid1: Fix data corruption for degraded array with slow disk
https://notcve.org/view.php?id=CVE-2024-45023
In the Linux kernel, the following vulnerability has been resolved: md/raid1: Fix data corruption for degraded array with slow disk read_balance() will avoid reading from slow disks as much as possible, however, if valid data only lands in slow disks, and a new normal disk is still in recovery, unrecovered data can be read: raid1_read_request read_balance raid1_should_read_first -> return false choose_best_rdev -> normal disk is not recovered, return -1 choose_bb_rdev -> missing the checking of recovery, return the normal disk -> read unrecovered data Root cause is that the checking of recovery is missing in choose_bb_rdev(). • https://git.kernel.org/stable/c/9f3ced792203891b8fa39afa37908eba843fcfac https://git.kernel.org/stable/c/2febf5fdbf5d9a52ddc3e986971c8609b1582d67 https://git.kernel.org/stable/c/c916ca35308d3187c9928664f9be249b22a3a701 •