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 •
CVSS: -EPSS: 0%CPEs: 1EXPL: 0CVE-2023-52916 – media: aspeed: Fix memory overwrite if timing is 1600x900
https://notcve.org/view.php?id=CVE-2023-52916
In the Linux kernel, the following vulnerability has been resolved: media: aspeed: Fix memory overwrite if timing is 1600x900 When capturing 1600x900, system could crash when system memory usage is tight. The way to reproduce this issue: 1. Use 1600x900 to display on host 2. Mount ISO through 'Virtual media' on OpenBMC's web 3. Run script as below on host to do sha continuously #!/bin/bash while [ [1] ]; do find /media -type f -printf '"%h/%f"\n' | xargs sha256sum done 4. • https://git.kernel.org/stable/c/c281355068bc258fd619c5aefd978595bede7bfe •