CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46676 – nfc: pn533: Add poll mod list filling check
https://notcve.org/view.php?id=CVE-2024-46676
In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Add poll mod list filling check In case of im_protocols value is 1 and tm_protocols value is 0 this combination successfully passes the check 'if (!im_protocols && !tm_protocols)' in the nfc_start_poll(). But then after pn533_poll_create_mod_list() call in pn533_start_poll() poll mod list will remain empty and dev->poll_mod_count will remain 0 which lead to division by zero. Normally no im protocol has value 1 in the mask, so this combination is not expected by driver. But these protocol values actually come from userspace via Netlink interface (NFC_CMD_START_POLL operation). So a broken or malicious program may pass a message containing a "bad" combination of protocol parameter values so that dev->poll_mod_count is not incremented inside pn533_poll_create_mod_list(), thus leading to division by zero. Call trace looks like: nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll() Add poll mod list filling check. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/dfccd0f580445d176acea174175b3e6518cc91f7 https://git.kernel.org/stable/c/c5e05237444f32f6cfe5d907603a232c77a08b31 https://git.kernel.org/stable/c/8ddaea033de051ed61b39f6b69ad54a411172b33 https://git.kernel.org/stable/c/7535db0624a2dede374c42040808ad9a9101d723 https://git.kernel.org/stable/c/7ecd3dd4f8eecd3309432156ccfe24768e009ec4 https://git.kernel.org/stable/c/56ad559cf6d87f250a8d203b555dfc3716afa946 https://git.kernel.org/stable/c/64513d0e546a1f19e390f7e5eba3872bfcbdacf5 https://git.kernel.org/stable/c/febccb39255f9df35527b88c953b2e0de •
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 •