CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46853 – spi: nxp-fspi: fix the KASAN report out-of-bounds bug
https://notcve.org/view.php?id=CVE-2024-46853
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/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dump_backtrace+0x90/0xe8 [ 36.967414] show_stack+0x18/0x24 [ 36.970749] dump_stack_lvl+0x78/0x90 [ 36.974451] print_report+0x114/0x5cc [ 36.978151] kasan_report+0xa4/0xf0 [ 36.981670] __asan_report_load_n_noabort+0x1c/0x28 [ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838 [ 36.990800] spi_mem_exec_op+0x8ec/0xd30 [ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0 [ 36.999323] spi_mem_dirmap_write+0x238/0x32c [ 37.003710] spi_nor_write_data+0x220/0x374 [ 37.007932] spi_nor_write+0x110/0x2e8 [ 37.011711] mtd_write_oob_std+0x154/0x1f0 [ 37.015838] mtd_write_oob+0x104/0x1d0 [ 37.019617] mtd_write+0xb8/0x12c [ 37.022953] mtdchar_write+0x224/0x47c [ 37.026732] vfs_write+0x1e4/0x8c8 [ 37.030163] ksys_write+0xec/0x1d0 [ 37.033586] __arm64_sys_write+0x6c/0x9c [ 37.037539] invoke_syscall+0x6c/0x258 [ 37.041327] el0_svc_common.constprop.0+0x160/0x22c [ 37.046244] do_el0_svc+0x44/0x5c [ 37.049589] el0_svc+0x38/0x78 [ 37.052681] el0t_64_sync_handler+0x13c/0x158 [ 37.057077] el0t_64_sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasan_save_stack+0x2c/0x54 [ 37.069570] kasan_save_track+0x20/0x3c [ 37.073438] kasan_save_alloc_info+0x40/0x54 [ 37.077736] __kasan_kmalloc+0xa0/0xb8 [ 37.081515] __kmalloc_noprof+0x158/0x2f8 [ 37.085563] mtd_kmalloc_up_to+0x120/0x154 [ 37.089690] mtdchar_write+0x130/0x47c [ 37.093469] vfs_write+0x1e4/0x8c8 [ 37.096901] ksys_write+0xec/0x1d0 [ 37.100332] __arm64_sys_write+0x6c/0x9c [ 37.104287] invoke_syscall+0x6c/0x258 [ 37.108064] el0_svc_common.constprop.0+0x160/0x22c [ 37.112972] do_el0_svc+0x44/0x5c [ 37.116319] el0_svc+0x38/0x78 [ 37.119401] el0t_64_sync_handler+0x13c/0x158 [ 37.123788] el0t_64_sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ============================================================== ---truncated--- • https://git.kernel.org/stable/c/a5356aef6a907c2e2aed0caaa2b88b6021394471 https://git.kernel.org/stable/c/aa05db44db5f409f6d91c27b5737efb49fb45d9f https://git.kernel.org/stable/c/609260542cf86b459c57618b8cdec8020394b7ad https://git.kernel.org/stable/c/491f9646f7ac31af5fca71be1a3e5eb8aa7663ad https://git.kernel.org/stable/c/09af8b0ba70072be831f3ec459f4063d570f9e24 https://git.kernel.org/stable/c/af9ca9ca3e44f48b2a191e100d452fbf850c3d87 https://git.kernel.org/stable/c/d1a1dfcec77c57b1181da93d11a3db1bc4eefa97 https://git.kernel.org/stable/c/2a8787c1cdc7be24fdd8953ecd1a8743a •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46852 – dma-buf: heaps: Fix off-by-one in CMA heap fault handler
https://notcve.org/view.php?id=CVE-2024-46852
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 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. • https://git.kernel.org/stable/c/a5d2d29e24be8967ef78a1b1fb2292413e3b3df9 https://git.kernel.org/stable/c/007180fcb6cc4a93211d4cc45fef3f5ccccd56ae 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/ea5ff5d351b520524019f7ff7f9ce418de2dad87 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46849 – ASoC: meson: axg-card: fix 'use-after-free'
https://notcve.org/view.php?id=CVE-2024-46849
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-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_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 • https://git.kernel.org/stable/c/7864a79f37b55769b817d5e6c5ae0ca4bfdba93b https://git.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/4f9a71435953f941969a4f017e2357db6 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46848 – perf/x86/intel: Limit the period on Haswell
https://notcve.org/view.php?id=CVE-2024-46848
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 ? • https://git.kernel.org/stable/c/3a632cb229bfb18b6d09822cc842451ea46c013e 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/25dfc9e357af8aed1ca79b318a73f2c59c1f0b2b •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46847 – mm: vmalloc: ensure vmap_block is initialised before adding to queue
https://notcve.org/view.php?id=CVE-2024-46847
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. 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 'vb->cpu' in new_vmap_block() ahead of the addition to the xarray. • https://git.kernel.org/stable/c/88e0ad40d08a73a74c597e69f4cd2d1fba3838b5 https://git.kernel.org/stable/c/8c61291fd8500e3b35c7ec0c781b273d8cc96cde https://git.kernel.org/stable/c/9983b81579be3403f5cc44b11f66c6c8bea6547f https://git.kernel.org/stable/c/1b2770e27d6d952f491bb362b657e5b2713c3efd https://git.kernel.org/stable/c/6cf74e0e5e3ab5d5c9defb4c73dad54d52224671 https://git.kernel.org/stable/c/3e3de7947c751509027d26b679ecd243bc9db255 •