CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46674 – usb: dwc3: st: fix probed platform device ref count on probe error path
https://notcve.org/view.php?id=CVE-2024-46674
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: st: fix probed platform device ref count on probe error path The probe function never performs any paltform device allocation, thus error path "undo_platform_dev_alloc" is entirely bogus. It drops the reference count from the platform device being probed. If error path is triggered, this will lead to unbalanced device reference counts and premature release of device resources, thus possible use-after-free when releasing remaining devm-managed resources. • https://git.kernel.org/stable/c/f83fca0707c66e36f14efef7f68702cb12de70b7 https://git.kernel.org/stable/c/b0979a885b9d4df2a25b88e9d444ccaa5f9f495c https://git.kernel.org/stable/c/f3498650df0805c75b4e1c94d07423c46cbf4ce1 https://git.kernel.org/stable/c/6aee4c5635d81f4809c3b9f0c198a65adfbb2ada https://git.kernel.org/stable/c/060f41243ad7f6f5249fa7290dda0c01f723d12d https://git.kernel.org/stable/c/4c6735299540f3c82a5033d35be76a5c42e0fb18 https://git.kernel.org/stable/c/e1e5e8ea2731150d5ba7c707f9e02fafebcfeb49 https://git.kernel.org/stable/c/1de989668708ce5875efc9d669d227212 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46673 – scsi: aacraid: Fix double-free on probe failure
https://notcve.org/view.php?id=CVE-2024-46673
In the Linux kernel, the following vulnerability has been resolved: scsi: aacraid: Fix double-free on probe failure aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init pointer, all of which eventually call down to aac_init_adapter(). If aac_init_adapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member. After the hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free. • https://git.kernel.org/stable/c/8e0c5ebde82b08f6d996e11983890fc4cc085fab https://git.kernel.org/stable/c/d237c7d06ffddcdb5d36948c527dc01284388218 https://git.kernel.org/stable/c/564e1986b00c5f05d75342f8407f75f0a17b94df https://git.kernel.org/stable/c/9e96dea7eff6f2bbcd0b42a098012fc66af9eb69 https://git.kernel.org/stable/c/85449b28ff6a89c4513115e43ddcad949b5890c9 https://git.kernel.org/stable/c/60962c3d8e18e5d8dfa16df788974dd7f35bd87a https://git.kernel.org/stable/c/8a3995a3ffeca280a961b59f5c99843d81b15929 https://git.kernel.org/stable/c/4b540ec7c0045c2d01c4e479f34bbc8f1 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-45028 – mmc: mmc_test: Fix NULL dereference on allocation failure
https://notcve.org/view.php?id=CVE-2024-45028
In the Linux kernel, the following vulnerability has been resolved: mmc: mmc_test: Fix NULL dereference on allocation failure If the "test->highmem = alloc_pages()" allocation fails then calling __free_pages(test->highmem) will result in a NULL dereference. Also change the error code to -ENOMEM instead of returning success. • https://git.kernel.org/stable/c/2661081f5ab9cb25359d27f88707a018cf4e68e9 https://git.kernel.org/stable/c/e97be13a9f51284da450dd2a592e3fa87b49cdc9 https://git.kernel.org/stable/c/2b507b03991f44dfb202fc2a82c9874d1b1f0c06 https://git.kernel.org/stable/c/9b9ba386d7bfdbc38445932c90fa9444c0524bea https://git.kernel.org/stable/c/e40515582141a9e7c84b269be699c05236a499a6 https://git.kernel.org/stable/c/3b4e76ceae5b5a46c968bd952f551ce173809f63 https://git.kernel.org/stable/c/cac2815f49d343b2f0acc4973d2c14918ac3ab0c https://git.kernel.org/stable/c/ecb15b8ca12c0cbdab81e307e9795214d •
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. What it does is copying enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, *if* all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied. For most of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in ->full_fds_bits[] correspond to. The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds), which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expand_fdtable() is safe. Unfortunately, there is a case where max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open. The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first. * new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size). * make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset(). Reproducer added to tools/testing/selftests/core/close_range_test.c • 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 •