Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2024-35799 State: PUBLISHED Published: 2024-05-17T13:23:09.515Z Last Updated: 2025-07-17T14:07:44.550Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Prevent crash when disable stream [Why] Disabling stream encoder invokes a function that no longer exists. [How] Check if the function declaration is NULL in disable stream encoder. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/4356a2c3f296503c8b420ae8adece053960a9f06 - https://git.kernel.org/stable/c/59772327d439874095516673b4b30c48bd83ca38 - https://git.kernel.org/stable/c/2b
960a9f06 - https://git.kernel.org/stable/c/59772327d439874095516673b4b30c48bd83ca38 - https://git.kernel.org/stable/c/2b17133a0a2e0e111803124dad09e803718d4a48 - https://git.kernel.org/stable/c/72d72e8fddbcd6c98e1b02d32cf6f2b04e10bd1c
CVE ID: CVE-2024-35800 State: PUBLISHED Published: 2024-05-17T13:23:10.170Z Last Updated: 2025-05-04T09:05:42.183Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: efi: fix panic in kdump kernel Check if get_next_variable() is actually valid pointer before calling it. In kdump kernel this method is set to NULL that causes panic during the kexec-ed kernel boot. Tested with QEMU and OVMF firmware. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b9d103aca85f082a343b222493f3cab1219aaaf4 - https://git.kernel.org/stable/c/9114ba9987506bcfbb454f6e68558d68cb1abbde
e/c/b9d103aca85f082a343b222493f3cab1219aaaf4 - https://git.kernel.org/stable/c/9114ba9987506bcfbb454f6e68558d68cb1abbde - https://git.kernel.org/stable/c/7784135f134c13af17d9ffb39a57db8500bc60ff - https://git.kernel.org/stable/c/090d2b4515ade379cd592fbc8931344945978210 - https://git.kernel.org/stable/c/62b71cd73d41ddac6b1760402bbe8c4932e23531
CVE ID: CVE-2024-35801 State: PUBLISHED Published: 2024-05-17T13:23:10.830Z Last Updated: 2025-05-04T09:05:43.500Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in order to avoid unnecessary writes to the MSR. On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of s
_fpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of sync. As a consequence a subsequent xfd_update_state() might fail to update the MSR which in turn can result in XRSTOR raising a #NM in kernel space, which crashes the kernel. To fix this, introduce xfd_set_state() to write xfd_state together with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/21c7c00dae55cb0e3810d5f9506b58f68475d41d - https://git.kernel.org/stable/c/1acbca933313aa866e39996904c9aca4d435c4cd - https://git.kernel.org/stable/c
8f68475d41d - https://git.kernel.org/stable/c/1acbca933313aa866e39996904c9aca4d435c4cd - https://git.kernel.org/stable/c/92b0f04e937665bde5768f3fcc622dcce44413d8 - https://git.kernel.org/stable/c/b61e3b7055ac6edee4be071c52f48c26472d2624 - https://git.kernel.org/stable/c/10e4b5166df9ff7a2d5316138ca668b42d004422
CVE ID: CVE-2024-35802 State: REJECTED Published: 2024-05-17T13:23:11.514Z Last Updated: 2024-05-28T19:07:51.467Z Description: No description available.
CVE ID: CVE-2024-35803 State: PUBLISHED Published: 2024-05-17T13:23:12.183Z Last Updated: 2025-05-04T09:05:44.716Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/efistub: Call mixed mode boot services on the firmware's stack Normally, the EFI stub calls into the EFI boot services using the stack that was live when the stub was entered. According to the UEFI spec, this stack needs to be at least 128k in size - this might seem large but all asynchronous processing and event handling in EFI runs from the same stack and so quite a lot of space may be used in practice. In mixed mode, the situation is a bit different: the bootloa
stack and so quite a lot of space may be used in practice. In mixed mode, the situation is a bit different: the bootloader calls the 32-bit EFI stub entry point, which calls the decompressor's 32-bit entry point, where the boot stack is set up, using a fixed allocation of 16k. This stack is still in use when the EFI stub is started in 64-bit mode, and so all calls back into the EFI firmware will be using the decompressor's limited boot stack. Due to the placement of the boot stack right after the boot heap, any stack overruns have gone unnoticed. However, commit 5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code") moved the definition of the boot heap into C code,
11983b ("x86/decompressor: Move global symbol references to C code") moved the definition of the boot heap into C code, and now the boot stack is placed right at the base of BSS, where any overruns will corrupt the end of the .data section. While it would be possible to work around this by increasing the size of the boot stack, doing so would affect all x86 systems, and mixed mode systems are a tiny (and shrinking) fraction of the x86 installed base. So instead, record the firmware stack pointer value when entering from the 32-bit firmware, and switch to this stack every time a EFI boot service call is made. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: Referenc
me a EFI boot service call is made. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/2149f8a56e2ed345c7a4d022a79f6b8fc53ae926 - https://git.kernel.org/stable/c/930775060ca348b8665f60eef14b204172d14f31 - https://git.kernel.org/stable/c/fba7ee7187581b5bc222003e73e2592b398bb06d - https://git.kernel.org/stable/c/725351c036452b7db5771a7bed783564bc4b99cc - https://git.kernel.org/stable/c/cefcd4fe2e3aaf792c14c9e56dab89e3d7a65d02
CVE ID: CVE-2024-35804 State: PUBLISHED Published: 2024-05-17T13:23:12.895Z Last Updated: 2025-05-04T12:55:47.713Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Mark target gfn of emulated atomic instruction as dirty When emulating an atomic access on behalf of the guest, mark the target gfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. This fixes a bug where KVM effectively corrupts guest memory during live migration by writing to guest memory without informing userspace that the page is dirty. Marking the page dirty got unintentionally dropped when KVM's emulated CMPXCHG was converted to do a user acc
is dirty. Marking the page dirty got unintentionally dropped when KVM's emulated CMPXCHG was converted to do a user access. Before that, KVM explicitly mapped the guest page into kernel memory, and marked the page dirty during the unmap phase. Mark the page dirty even if the CMPXCHG fails, as the old data is written back on failure, i.e. the page is still written. The value written is guaranteed to be the same because the operation is atomic, but KVM's ABI is that all writes are dirty logged regardless of the value written. And more importantly, that's what KVM did before the buggy commit. Huge kudos to the folks on the Cc list (and many others), who did all the actual work of triaging and
the buggy commit. Huge kudos to the folks on the Cc list (and many others), who did all the actual work of triaging and debugging. base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/a9bd6bb6f02bf7132c1ab192ba62bbfa52df7d66 - https://git.kernel.org/stable/c/726374dde5d608b15b9756bd52b6fc283fda7a06 - https://git.kernel.org/stable/c/9d1b22e573a3789ed1f32033ee709106993ba551 - https://git.kernel.org/stable/c/225d587a073584946c05c9b7651d637bd45c0c71 - https://git.kernel.org/stable/c/910c57dfa4d113aae6571c2a8b9ae8c430975902
CVE ID: CVE-2024-35805 State: PUBLISHED Published: 2024-05-17T13:23:13.554Z Last Updated: 2025-05-04T09:05:47.748Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm snapshot: fix lockup in dm_exception_table_exit There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/e7d4cff57c3c43fdd72342c78d4138f509c7416e - https://git.kernel.org/stable/c/9759ff196e7d248bcf8386a7451d6ff8537a7d9c - https://git.kernel.org/stable/c/11656
7416e - https://git.kernel.org/stable/c/9759ff196e7d248bcf8386a7451d6ff8537a7d9c - https://git.kernel.org/stable/c/116562e804ffc9dc600adab6326dde31d72262c7 - https://git.kernel.org/stable/c/3d47eb405781cc5127deca9a14e24b27696087a1 - https://git.kernel.org/stable/c/e50f83061ac250f90710757a3e51b70a200835e2 - https://git.kernel.org/stable/c/fa5c055800a7fd49a36bbb52593aca4ea986a366 - https://git.kernel.org/stable/c/5f4ad4d0b0943296287313db60b3f84df4aad683 - https://git.kernel.org/stable/c/6e7132ed3c07bd8a6ce3db4bb307ef2852b322dc
CVE ID: CVE-2024-35806 State: PUBLISHED Published: 2024-05-17T13:23:14.214Z Last Updated: 2025-05-04T12:55:48.844Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: Always disable interrupts when taking cgr_lock smp_call_function_single disables IRQs when executing the callback. To prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere. This is already done by qman_update_cgr and qman_delete_cgr; fix the other lockers. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b56a793f267679945d1fdb9a280013bd2d0ed7f9 - https://git.kerne
am Container: References: - https://git.kernel.org/stable/c/b56a793f267679945d1fdb9a280013bd2d0ed7f9 - https://git.kernel.org/stable/c/62c3ecd2833cff0eff4a82af4082c44ca8d2518a - https://git.kernel.org/stable/c/dd199e5b759ffe349622a4b8fbcafc51fc51b1ec - https://git.kernel.org/stable/c/e6378314bb920acb39013051fa65d8f9f8030430 - https://git.kernel.org/stable/c/a62168653774c36398d65846a98034436ee66d03 - https://git.kernel.org/stable/c/0e6521b0f93ff350434ed4ae61a250907e65d397 - https://git.kernel.org/stable/c/276af8efb05c8e47acf2738a5609dd72acfc703f - https://git.kernel.org/stable/c/af25c5180b2b1796342798f6c56fcfd12f5035bd - https://git.kernel.org/stable/c/584c2a9184a33a40fceee838f856de3cffa19be3
CVE ID: CVE-2024-35807 State: PUBLISHED Published: 2024-05-17T13:23:14.869Z Last Updated: 2025-05-04T09:05:50.120Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix corruption during on-line resize We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/
ine resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number
est # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that ar
n the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/75cc31c2e7193b69f5d25650bda5bb42ed92f8a1 - https://git.kernel.org/sta
ner: References: - https://git.kernel.org/stable/c/75cc31c2e7193b69f5d25650bda5bb42ed92f8a1 - https://git.kernel.org/stable/c/ee4e9c1976147a850f6085a13fca95bcaa00d84c - https://git.kernel.org/stable/c/e8e8b197317228b5089ed9e7802dadf3ccaa027a - https://git.kernel.org/stable/c/239c669edb2bffa1aa2612519b1d438ab35d6be6 - https://git.kernel.org/stable/c/fb1088d51bbaa0faec5a55d4f5818a9ab79e24df - https://git.kernel.org/stable/c/37b6a3ba793bbbae057f5b991970ebcc52cb3db5 - https://git.kernel.org/stable/c/b461910af8ba3bed80f48c2bf852686d05c6fc5c - https://git.kernel.org/stable/c/722d2c01b8b108f8283d1b7222209d5b2a5aa7bd - https://git.kernel.org/stable/c/a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc
CVE ID: CVE-2024-35808 State: PUBLISHED Published: 2024-05-17T13:23:15.515Z Last Updated: 2025-05-04T09:05:51.587Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md/dm-raid: don't call md_reap_sync_thread() directly Currently md_reap_sync_thread() is called from raid_message() directly without holding 'reconfig_mutex', this is definitely unsafe because md_reap_sync_thread() can change many fields that is protected by 'reconfig_mutex'. However, hold 'reconfig_mutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock"). Fix this pro
ause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock"). Fix this problem by using stop_sync_thread() to unregister sync_thread, like md/raid did. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/347dcdc15a1706f61aa545ae498ededdf31aeebc - https://git.kernel.org/stable/c/9e59b8d76ff511505eb0dd1478329f09e0f04669 - https://git.kernel.org/stable/c/cd32b27a66db8776d8b8e82ec7d7dde97a8693b0
CVE ID: CVE-2024-35809 State: PUBLISHED Published: 2024-05-17T13:23:16.168Z Last Updated: 2025-05-04T09:05:53.318Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI/PM: Drain runtime-idle callbacks before driver removal A race condition between the .runtime_idle() callback and the .remove() callback in the rtsx_pcr PCI driver leads to a kernel crash due to an unhandled page fault [1]. The problem is that rtsx_pci_runtime_idle() is not expected to be running after pm_runtime_get_sync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when
latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns. However, if a .runtime_idle() callback is already running when pm_runtime_get_sync() is called, the latter will notice that the runtime PM status of the device is RPM_ACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtime_idle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited). Thus in general, whoever is providing a .runtime_idle() callback needs to protect it from running in parallel with whatever code runs
al, whoever is providing a .runtime_idle() callback needs to protect it from running in parallel with whatever code runs after pm_runtime_get_sync(). [Note that .runtime_idle() will not start after pm_runtime_get_sync() has returned, but it may continue running then if it has started earlier.] One way to address that race condition is to call pm_runtime_barrier() after pm_runtime_get_sync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtime_idle() callback to complete should it be running at that point. A suitable place for doing that is in pci_device_remove() which calls pm_runtime
ete should it be running at that point. A suitable place for doing that is in pci_device_remove() which calls pm_runtime_get_sync() before removing the driver, so it may as well call pm_runtime_barrier() subsequently, which will prevent the race in question from occurring, not just in the rtsx_pcr driver, but in any PCI drivers providing .runtime_idle() callbacks. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/9a87375bb586515c0af63d5dcdcd58ec4acf20a6 - https://git.kernel.org/stable/c/47d8aafcfe313511a98f165a54d0adceb34e54b1 - https://git.kernel.org/stable/c/bbe068b24409ef740657215605284fc7cdddd491 - https://git.kernel
a98f165a54d0adceb34e54b1 - https://git.kernel.org/stable/c/bbe068b24409ef740657215605284fc7cdddd491 - https://git.kernel.org/stable/c/7cc94dd36e48879e76ae7a8daea4ff322b7d9674 - https://git.kernel.org/stable/c/900b81caf00c89417172afe0e7e49ac4eb110f4b - https://git.kernel.org/stable/c/d86ad8c3e152349454b82f37007ff6ba45f26989 - https://git.kernel.org/stable/c/d534198311c345e4b062c4b88bb609efb8bd91d5 - https://git.kernel.org/stable/c/6347348c6aba52dda0b33296684cbb627bdc6970 - https://git.kernel.org/stable/c/9d5286d4e7f68beab450deddbb6a32edd5ecf4bf
CVE ID: CVE-2024-35810 State: PUBLISHED Published: 2024-05-17T13:23:16.829Z Last Updated: 2025-05-04T09:05:54.753Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix the lifetime of the bo cursor memory The cleanup can be dispatched while the atomic update is still active, which means that the memory acquired in the atomic update needs to not be invalidated by the cleanup. The buffer objects in vmw_plane_state instead of using the builtin map_and_cache were trying to handle the lifetime of the mapped memory themselves, leading to crashes. Use the map_and_cache instead of trying to manage the lifetime of the buffer o
ed memory themselves, leading to crashes. Use the map_and_cache instead of trying to manage the lifetime of the buffer objects held by the vmw_plane_state. Fixes kernel oops'es in IGT's kms_cursor_legacy forked-bo. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/86cb706a40b7e6b2221ee49a298a65ad9b46c02d - https://git.kernel.org/stable/c/104a5b2772bc7c0715ae7355ccf9d294a472765c - https://git.kernel.org/stable/c/ed381800ea6d9a4c7f199235a471c0c48100f0ae - https://git.kernel.org/stable/c/9a9e8a7159ca09af9b1a300a6c8e8b6ff7501c76
CVE ID: CVE-2024-35811 State: PUBLISHED Published: 2024-05-17T13:23:17.508Z Last Updated: 2025-05-04T09:05:55.989Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233 In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); If we dis
->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is : brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker. Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach. [arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free] Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: Re
e as is and cancel work just before free] Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/202c503935042272e2f9e1bb549d5f69a8681169 - https://git.kernel.org/stable/c/8e3f03f4ef7c36091f46e7349096efb5a2cdb3a1 - https://git.kernel.org/stable/c/bacb8c3ab86dcd760c15903fcee58169bc3026aa - https://git.kernel.org/stable/c/8c36205123dc57349b59b4f1a2301eb278cbc731 - https://git.kernel.org/stable/c/0b812f706fd7090be74812101114a0e165b36744 - https://git.kernel.org/stable/c/190794848e2b9d15de92d502b6ac652806904f5a - https://git.kernel.org/stable/c/6678a1e7d896c00030b31491690e8ddc9a90767a - https://git.kernel.org/stable/c/0a7591e14a8
- https://git.kernel.org/stable/c/6678a1e7d896c00030b31491690e8ddc9a90767a - https://git.kernel.org/stable/c/0a7591e14a8da794d0b93b5d1c6254ccb23adacb - https://git.kernel.org/stable/c/0f7352557a35ab7888bc7831411ec8a3cbe20d78
CVE ID: CVE-2024-35812 State: REJECTED Published: 2024-05-17T13:23:18.177Z Last Updated: 2024-06-04T12:56:46.024Z Description: No description available.
CVE ID: CVE-2024-35813 State: PUBLISHED Published: 2024-05-17T13:23:18.902Z Last Updated: 2025-05-04T09:05:57.228Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mmc: core: Avoid negative index with array access Commit 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu") assigns prev_idata = idatas[i - 1], but doesn't check that the iterator i is greater than zero. Let's fix this by adding a check. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b9a7339ae403035ffe7fc37cb034b36947910f68 - https://git.kernel.org/stable/c/2b539c88940e22494da80a93ee1c5a
l.org/stable/c/b9a7339ae403035ffe7fc37cb034b36947910f68 - https://git.kernel.org/stable/c/2b539c88940e22494da80a93ee1c5a28bbad10f6 - https://git.kernel.org/stable/c/81b8645feca08a54c7c4bf36e7b176f4983b2f28 - https://git.kernel.org/stable/c/ad9cc5e9e53ab94aa0c7ac65d43be7eb208dcb55 - https://git.kernel.org/stable/c/4466677dcabe2d70de6aa3d4bd4a4fafa94a71f2 - https://git.kernel.org/stable/c/064db53f9023a2d5877a2d12de6bc27995f6ca56 - https://git.kernel.org/stable/c/7d0e8a6147550aa058fa6ade8583ad252aa61304 - https://git.kernel.org/stable/c/cf55a7acd1ed38afe43bba1c8a0935b51d1dc014