CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46675 – usb: dwc3: core: Prevent USB core invalid event buffer address access
https://notcve.org/view.php?id=CVE-2024-46675
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: Prevent USB core invalid event buffer address access This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address. To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address. • https://git.kernel.org/stable/c/eca3f543f817da87c00d1a5697b473efb548204f https://git.kernel.org/stable/c/d2afc2bffec77316b90d530b07695e3f534df914 https://git.kernel.org/stable/c/b72da4d89b97da71e056cc4d1429b2bc426a9c2f https://git.kernel.org/stable/c/111277b881def3153335acfe0d1f43e6cd83ac93 https://git.kernel.org/stable/c/2189fd13c577d7881f94affc09c950a795064c4b https://git.kernel.org/stable/c/7bb11a75dd4d3612378b90e2a4aa49bdccea28ab https://git.kernel.org/stable/c/e23f6ad8d110bf632f7471482e10b43dc174fb72 https://git.kernel.org/stable/c/14e497183df28c006603cc67fd3797a53 •
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: 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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-45021 – memcg_write_event_control(): fix a user-triggerable oops
https://notcve.org/view.php?id=CVE-2024-45021
In the Linux kernel, the following vulnerability has been resolved: memcg_write_event_control(): fix a user-triggerable oops we are *not* guaranteed that anything past the terminating NUL is mapped (let alone initialized with anything sane). • https://git.kernel.org/stable/c/0dea116876eefc9c7ca9c5d74fe665481e499fa3 https://git.kernel.org/stable/c/fa5bfdf6cb5846a00e712d630a43e3cf55ccb411 https://git.kernel.org/stable/c/1b37ec85ad95b612307627758c6018cd9d92cca8 https://git.kernel.org/stable/c/ad149f5585345e383baa65f1539d816cd715fd3b https://git.kernel.org/stable/c/0fbe2a72e853a1052abe9bc2b7df8ddb102da227 https://git.kernel.org/stable/c/43768fa80fd192558737e24ed6548f74554611d7 https://git.kernel.org/stable/c/f1aa7c509aa766080db7ab3aec2e31b1df09e57c https://git.kernel.org/stable/c/21b578f1d599edb87462f11113c5b0fc7 •