Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2024-46838 State: PUBLISHED Published: 2024-09-27T12:39:33.755Z Last Updated: 2025-05-04T09:35:39.617Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: userfaultfd: don't BUG_ON() if khugepaged yanks our page table Since khugepaged was changed to allow retracting page tables in file mappings without holding the mmap lock, these BUG_ON()s are wrong - get rid of them. We could also remove the preceding "if (unlikely(...))" block, but then we could reach pte_offset_map_lock() with transhuge pages not just for file mappings but also for anonymous mappings - which would probably be fine but I think is not necessarily expec
st for file mappings but also for anonymous mappings - which would probably be fine but I think is not necessarily expected. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/4a594acc12d5954cdc71d4450a386748bf3d136a - https://git.kernel.org/stable/c/db978287e908d48b209e374b00d847b2d785e0a9 - https://git.kernel.org/stable/c/4828d207dc5161dc7ddf9a4f6dcfd80c7dd7d20a
CVE ID: CVE-2024-46839 State: REJECTED Published: 2024-09-27T12:39:34.371Z Last Updated: 2024-10-01T13:53:07.501Z Description: No description available.
CVE ID: CVE-2024-46840 State: PUBLISHED Published: 2024-09-27T12:39:34.998Z Last Updated: 2025-11-03T22:19:28.536Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: clean up our handling of refs == 0 in snapshot delete In reada we BUG_ON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In do_walk_down() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error
k_down() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/c847b28a799733b04574060ab9d00f215970627d - https://git.kernel.org/stable/c/71291aa7246645ef622621934d2067400380645e - https://git.kernel.org/stable/c/c60676b81fab456b672796830f6d8057058f029c - https://git.kernel.org/stable/c/728d4d045b628e006b48a448f3326a7194c88d32
e/c/c60676b81fab456b672796830f6d8057058f029c - https://git.kernel.org/stable/c/728d4d045b628e006b48a448f3326a7194c88d32 - https://git.kernel.org/stable/c/9cc887ac24b7a0598f4042ae9af6b9a33072f75b - https://git.kernel.org/stable/c/7d1df13bf078ffebfedd361d714ff6cee1ff01b9 - https://git.kernel.org/stable/c/03804641ec2d0da4fa088ad21c88e703d151ce16 - https://git.kernel.org/stable/c/b8ccef048354074a548f108e51d0557d6adfd3a3
CVE ID: CVE-2024-46841 State: PUBLISHED Published: 2024-09-27T12:39:35.633Z Last Updated: 2025-11-03T20:39:20.621Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc() We handle errors here properly, ENOMEM isn't fatal, return the error. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/c1406d8329f500e4594cd9730cd313aebc3a4333 - https://git.kernel.org/stable/c/6a0648f96c3ca647c71c6c1ddbc7c353bab79f64 - https://git.kernel.org/stable/c/44a2c518ab221c0cadcb8c45ca86f83a52dd4da6 - https:
48f96c3ca647c71c6c1ddbc7c353bab79f64 - https://git.kernel.org/stable/c/44a2c518ab221c0cadcb8c45ca86f83a52dd4da6 - https://git.kernel.org/stable/c/135b4819f6fba87fd5a2693023133e78ac73f1d3 - https://git.kernel.org/stable/c/704c359b4093a2af650a20eaa030c435d7c30f91 - https://git.kernel.org/stable/c/a580fb2c3479d993556e1c31b237c9e5be4944a3
CVE ID: CVE-2024-46842 State: PUBLISHED Published: 2024-09-27T12:39:36.370Z Last Updated: 2025-05-04T09:35:43.523Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info The MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the routine unconditionally frees submitted mailbox commands regardless of return status. The issue is that for MBX_TIMEOUT cases, when firmware returns SFP information at a later time, that same mailbox memory region references previously freed memory in its cmpl routine. Fix by adding checks for the MBX_TIMEOUT return code. During mailbox resou
previously freed memory in its cmpl routine. Fix by adding checks for the MBX_TIMEOUT return code. During mailbox resource cleanup, check the mbox flag to make sure that the wait did not timeout. If the MBOX_WAKE flag is not set, then do not free the resources because it will be freed when firmware completes the mailbox at a later time in its cmpl routine. Also, increase the timeout from 30 to 60 seconds to accommodate boot scripts requiring longer timeouts. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/bba47fe3b038cca3d3ebd799665ce69d6d273b58 - https://git.kernel.org/stable/c/ede596b1434b57c0b3fd5c02b326efe5c54f6e48
CVE ID: CVE-2024-46843 State: PUBLISHED Published: 2024-09-27T12:39:37.025Z Last Updated: 2025-05-21T09:13:17.306Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Remove SCSI host only if added If host tries to remove ufshcd driver from a UFS device it would cause a kernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before adding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host has been defered after MCQ configuration introduced by commit 0cab4023ec7b ("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported"). To guarantee that SCSI host is removed only if it has been added,
core: Defer adding host to SCSI if MCQ is supported"). To guarantee that SCSI host is removed only if it has been added, set the scsi_host_added flag to true after adding a SCSI host and check whether it is set or not before removing it. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2f49e05d6b58d660f035a75ff96b77071b4bd5ed - https://git.kernel.org/stable/c/3844586e9bd9845140e1078f1e61896b576ac536 - https://git.kernel.org/stable/c/7cbff570dbe8907e23bba06f6414899a0fbb2fcc
CVE ID: CVE-2024-46844 State: PUBLISHED Published: 2024-09-27T12:39:37.685Z Last Updated: 2025-11-03T22:19:31.529Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: um: line: always fill *error_out in setup_one_line() The pointer isn't initialized by callers, but I have encountered cases where it's still printed; initialize it in all possible cases in setup_one_line(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/3bedb7ce080690d0d6172db790790c1219bcbdd5 - https://git.kernel.org/stable/c/96301fdc2d533a196197c055af875fe33d47ef84 - https://git.kernel.org/sta
90790c1219bcbdd5 - https://git.kernel.org/stable/c/96301fdc2d533a196197c055af875fe33d47ef84 - https://git.kernel.org/stable/c/c8944d449fda9f58c03bd99649b2df09948fc874 - https://git.kernel.org/stable/c/43f782c27907f306c664b6614fd6f264ac32cce6 - https://git.kernel.org/stable/c/289979d64573f43df1d0e6bc6435de63a0d69cdf - https://git.kernel.org/stable/c/ec5b47a370177d79ae7773858042c107e21f8ecc - https://git.kernel.org/stable/c/fc843d3837ebcb1c16d3768ef3eb55e25d5331f2 - https://git.kernel.org/stable/c/824ac4a5edd3f7494ab1996826c4f47f8ef0f63d
CVE ID: CVE-2024-46845 State: PUBLISHED Published: 2024-09-27T12:39:38.315Z Last Updated: 2025-05-04T09:35:47.670Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Only clear timer if a kthread exists The timerlat tracer can use user space threads to check for osnoise and timer latency. If the program using this is killed via a SIGTERM, the threads are shutdown one at a time and another tracing instance can start up resetting the threads before they are fully closed. That causes the hrtimer assigned to the kthread to be shutdown and freed twice when the dying thread finally closes the file descriptors, causing a
igned to the kthread to be shutdown and freed twice when the dying thread finally closes the file descriptors, causing a use-after-free bug. Only cancel the hrtimer if the associated thread is still around. Also add the interface_lock around the resetting of the tlat_var->kthread. Note, this is just a quick fix that can be backported to stable. A real fix is to have a better synchronization between the shutdown of old threads and the starting of new ones. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8c72f0b2c45f21cb8b00fc37f79f632d7e46c2ed - https://git.kernel.org/stable/c/8a9d0d405159e9c796ddf771f7cff691c1a2bc1e - https://git.kernel.org/st
7f79f632d7e46c2ed - https://git.kernel.org/stable/c/8a9d0d405159e9c796ddf771f7cff691c1a2bc1e - https://git.kernel.org/stable/c/e6a53481da292d970d1edf0d8831121d1c5e2f0d
CVE ID: CVE-2024-46846 State: PUBLISHED Published: 2024-09-27T12:39:38.928Z Last Updated: 2025-11-03T22:19:33.010Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spi: rockchip: Resolve unbalanced runtime PM / system PM handling Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops") stopped respecting runtime PM status and simply disabled clocks unconditionally when suspending the system. This causes problems when the device is already runtime suspended when we go to sleep -- in which case we double-disable clocks and produce a WARNing. Switch back to pm_runtime_force_{suspend,resume}(
sleep -- in which case we double-disable clocks and produce a WARNing. Switch back to pm_runtime_force_{suspend,resume}(), because that still seems like the right thing to do, and the aforementioned commit makes no explanation why it stopped using it. Also, refactor some of the resume() error handling, because it's not actually a good idea to re-disable clocks on failure. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/14f970a8d03d882b15b97beb83bd84ac8ba6298c - https://git.kernel.org/stable/c/d034bff62faea1a2219e0d2f3d17263265f24087 - https://git.kernel.org/stable/c/0efbad8445fbba7896402500a1473450a299a08a - https://gi
2faea1a2219e0d2f3d17263265f24087 - https://git.kernel.org/stable/c/0efbad8445fbba7896402500a1473450a299a08a - https://git.kernel.org/stable/c/be721b451affbecc4ba4eaac3b71cdbdcade1b1b
CVE ID: CVE-2024-46847 State: PUBLISHED Published: 2024-09-27T12:39:39.550Z Last Updated: 2025-05-04T12:58:45.259Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm: vmalloc: ensure vmap_block is initialised before adding to queue Commit 8c61291fd850 ("mm: fix incorrect vbq reference in purge_fragmented_block") extended the 'vmap_block' structure to contain a 'cpu' field which is set at allocation time to the id of the initialising CPU. When a new 'vmap_block' is being instantiated by new_vmap_block(), the partially initialised structure is added to the local 'vmap_block_queue' xarray before the 'cpu' field has been initialised
tially initialised structure is added to the local 'vmap_block_queue' xarray before the 'cpu' field has been initialised. If another CPU is concurrently walking the xarray (e.g. via vm_unmap_aliases()), then it may perform an out-of-bounds access to the remote queue thanks to an uninitialised index. This has been observed as UBSAN errors in Android: | Internal error: UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP | | Call trace: | purge_fragmented_block+0x204/0x21c | _vm_unmap_aliases+0x170/0x378 | vm_unmap_aliases+0x1c/0x28 | change_memory_common+0x1dc/0x26c | set_memory_ro+0x18/0x24 | module_enable_ro+0x98/0x238 | do_init_module+0x1b0/0x310 Move the initialisation of '
/0x26c | set_memory_ro+0x18/0x24 | module_enable_ro+0x98/0x238 | do_init_module+0x1b0/0x310 Move the initialisation of 'vb->cpu' in new_vmap_block() ahead of the addition to the xarray. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/1b2770e27d6d952f491bb362b657e5b2713c3efd - https://git.kernel.org/stable/c/6cf74e0e5e3ab5d5c9defb4c73dad54d52224671 - https://git.kernel.org/stable/c/3e3de7947c751509027d26b679ecd243bc9db255
CVE ID: CVE-2024-46848 State: PUBLISHED Published: 2024-09-27T12:39:40.191Z Last Updated: 2025-11-03T22:19:34.473Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Limit the period on Haswell Running the ltp test cve-2015-3290 concurrently reports the following warnings. perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: <NMI> ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? h
ntel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330 Thanks to Thomas Gleixner's analysis, the issue is caused by the low initial period (1) of the frequency estimation algorithm, which triggers the defects of the HW, specifically erratum HSW11 and HSW143. (For the details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/) The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL event, but the initial period
87plq9l5d2.ffs@tglx/) The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL event, but the initial period in the freq mode is 1. The erratum is the same as the BDM11, which has been supported in the kernel. A minimum period of 128 is enforced as well on HSW. HSW143 is regarding that the fixed counter 1 may overcount 32 with the Hyper-Threading is enabled. However, based on the test, the hardware has more issues than it tells. Besides the fixed counter 1, the message 'interrupt took too long' can be observed on any counter which was armed with a period < 32 and two events expired in the same NMI. A minimum period of 32 is enforced for the rest of the events. The recommended wor
d two events expired in the same NMI. A minimum period of 32 is enforced for the rest of the events. The recommended workaround code of the HSW143 is not implemented. Because it only addresses the issue for the fixed counter. It brings extra overhead through extra MSR writing. No related overcounting issue has been reported so far. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/15210b7c8caff4929f25d049ef8404557f8ae468 - https://git.kernel.org/stable/c/0eaf812aa1506704f3b78be87036860e5d0fe81d - https://git.kernel.org/stable/c/8717dc35c0e5896f4110f4b3882f7ff787a5f73d - https://git.kernel.org/stable/c/25dfc9e357af8aed1ca
//git.kernel.org/stable/c/8717dc35c0e5896f4110f4b3882f7ff787a5f73d - https://git.kernel.org/stable/c/25dfc9e357af8aed1ca79b318a73f2c59c1f0b2b
CVE ID: CVE-2024-46849 State: PUBLISHED Published: 2024-09-27T12:42:43.316Z Last Updated: 2025-11-03T22:19:35.939Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: axg-card: fix 'use-after-free' Buffer 'card->dai_link' is reallocated in 'meson_card_reallocate_links()', so move 'pad' pointer initialization after this function when memory is already reallocated. Kasan bug report: ================================================================== BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc Read of size 8 at addr ffff000000e8b260 by task modprobe/356 CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12
6c/0x9bc Read of size 8 at addr ffff000000e8b260 by task modprobe/356 CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1 Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x78/0x90 print_report+0xfc/0x5c0 kasan_report+0xb8/0xfc __asan_load8+0x9c/0xb8 axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card] meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils] platform_probe+0x8c/0xf4 really_probe+0x110/0x39c __driver_probe_device+0xb8/0x18c driver_probe_device+0x108/0x1d8 __driver_attach+0xd0/0x25c bus_for_each_dev+0xe0/0x154 driver_attach+0x34/0x44 bus_add_driver+0x134/0x294 driver_register+0xa8/0x1e8 __platform_driver_register+0x44/0x54 axg_card_pdr
attach+0x34/0x44 bus_add_driver+0x134/0x294 driver_register+0xa8/0x1e8 __platform_driver_register+0x44/0x54 axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card] do_one_initcall+0xdc/0x25c do_init_module+0x10c/0x334 load_module+0x24c4/0x26cc init_module_from_file+0xd4/0x128 __arm64_sys_finit_module+0x1f4/0x41c invoke_syscall+0x60/0x188 el0_svc_common.constprop.0+0x78/0x13c do_el0_svc+0x30/0x40 el0_svc+0x38/0x78 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/a33145f494e6cb82f3e018662cc7c4febf271f22 - https://git.kernel.org/stable/c/5a2cc2bb81399e9ebc7256
it.kernel.org/stable/c/a33145f494e6cb82f3e018662cc7c4febf271f22 - https://git.kernel.org/stable/c/5a2cc2bb81399e9ebc72560541137eb04d61dc3d - https://git.kernel.org/stable/c/fb0530025d502cb79d2b2801b14a9d5261833f1a - https://git.kernel.org/stable/c/e1a199ec31617242e1a0ea8f312341e682d0c037 - https://git.kernel.org/stable/c/e43364f578cdc2f8083abbc0cb743ea55e827c29 - https://git.kernel.org/stable/c/7d318166bf55e9029d56997c3b134f4ac2ae2607 - https://git.kernel.org/stable/c/4f9a71435953f941969a4f017e2357db62d85a86
CVE ID: CVE-2024-46850 State: PUBLISHED Published: 2024-09-27T12:42:43.967Z Last Updated: 2025-05-04T09:35:54.764Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid race between dcn35_set_drr() and dc_state_destruct() dc_state_destruct() nulls the resource context of the DC state. The pipe context passed to dcn35_set_drr() is a member of this resource context. If dc_state_destruct() is called parallel to the IRQ processing (which calls dcn35_set_drr() at some point), we can end up using already nulled function callback fields of struct stream_resource. The logic in dcn35_set_drr() already tries to avoid this
eady nulled function callback fields of struct stream_resource. The logic in dcn35_set_drr() already tries to avoid this, by checking tg against NULL. But if the nulling happens exactly after the NULL check and before the next access, then we get a race. Avoid this by copying tg first to a local variable, and then use this variable for all the operations. This should work, as long as nobody frees the resource pool where the timing generators live. (cherry picked from commit 0607a50c004798a96e62c089a4c34c220179dcb5) Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/42850927656a540428e58d370b3c1599a617bac7 - https://git.kernel.org/stable/c/e835d51
es: - https://git.kernel.org/stable/c/42850927656a540428e58d370b3c1599a617bac7 - https://git.kernel.org/stable/c/e835d5144f5ef78e4f8828c63e2f0d61144f283a
CVE ID: CVE-2024-46851 State: PUBLISHED Published: 2024-09-27T12:42:44.619Z Last Updated: 2025-05-04T09:35:56.411Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid race between dcn10_set_drr() and dc_state_destruct() dc_state_destruct() nulls the resource context of the DC state. The pipe context passed to dcn10_set_drr() is a member of this resource context. If dc_state_destruct() is called parallel to the IRQ processing (which calls dcn10_set_drr() at some point), we can end up using already nulled function callback fields of struct stream_resource. The logic in dcn10_set_drr() already tries to avoid this
eady nulled function callback fields of struct stream_resource. The logic in dcn10_set_drr() already tries to avoid this, by checking tg against NULL. But if the nulling happens exactly after the NULL check and before the next access, then we get a race. Avoid this by copying tg first to a local variable, and then use this variable for all the operations. This should work, as long as nobody frees the resource pool where the timing generators live. (cherry picked from commit a3cc326a43bdc48fbdf53443e1027a03e309b643) Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b6ce047a81f508f5c60756db8dfb5ff486e4dad0 - https://git.kernel.org/stable/c/a7aeb03
es: - https://git.kernel.org/stable/c/b6ce047a81f508f5c60756db8dfb5ff486e4dad0 - https://git.kernel.org/stable/c/a7aeb03888b92304e2fc7d4d1c242f54a312561b
CVE ID: CVE-2024-46852 State: PUBLISHED Published: 2024-09-27T12:42:45.336Z Last Updated: 2025-11-03T22:19:37.416Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dma-buf: heaps: Fix off-by-one in CMA heap fault handler Until VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps: Don't track CMA dma-buf pages under RssFile") it was possible to obtain a mapping larger than the buffer size via mremap and bypass the overflow check in dma_buf_mmap_internal. When using such a mapping to attempt to fault past the end of the buffer, the CMA heap fault handler also checks the fault offset against the buffer size, but gets the
st the end of the buffer, the CMA heap fault handler also checks the fault offset against the buffer size, but gets the boundary wrong by 1. Fix the boundary check so that we don't read off the end of the pages array and insert an arbitrary page in the mapping. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/79cce5e81d20fa9ad553be439d665ac3302d3c95 - https://git.kernel.org/stable/c/84175dc5b2c932266a50c04e5ce342c30f817a2f - https://git.kernel.org/stable/c/eb7fc8b65cea22f9038c52398c8b22849e9620ea - https://git.kernel.org/stable/c/e79050882b857c37634baedbdcf7c2047c24cbff - https://git.kernel.org/stable/c/ea5ff5d351b52052
ps://git.kernel.org/stable/c/e79050882b857c37634baedbdcf7c2047c24cbff - https://git.kernel.org/stable/c/ea5ff5d351b520524019f7ff7f9ce418de2dad87
CVE ID: CVE-2024-46853 State: PUBLISHED Published: 2024-09-27T12:42:45.989Z Last Updated: 2025-11-03T22:19:38.858Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spi: nxp-fspi: fix the KASAN report out-of-bounds bug Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO. To reproduce the issue, write 3 bytes data to NOR chip. dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/45