CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2024-46855 – netfilter: nft_socket: fix sk refcount leaks
https://notcve.org/view.php?id=CVE-2024-46855
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_socket: fix sk refcount leaks We must put 'sk' reference before returning. • https://git.kernel.org/stable/c/039b1f4f24ecc8493b6bb9d70b4b78750d1b35c2 https://git.kernel.org/stable/c/6934809432d23e9e0081f82d882b8fc765deeb4a https://git.kernel.org/stable/c/f63432cd1bb224f61216e4a4726ff29ddffbed98 https://git.kernel.org/stable/c/33c2258bf8cb17fba9e58b111d4c4f4cf43a4896 https://git.kernel.org/stable/c/83e6fb59040e8964888afcaa5612cc1243736715 https://git.kernel.org/stable/c/1f68e097e20d3c695281a9c6433acc37be47fe11 https://git.kernel.org/stable/c/8b26ff7af8c32cb4148b3e147c52f9e4c695209c •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-46854 – net: dpaa: Pad packets to ETH_ZLEN
https://notcve.org/view.php?id=CVE-2024-46854
In the Linux kernel, the following vulnerability has been resolved: net: dpaa: Pad packets to ETH_ZLEN When sending packets under 60 bytes, up to three bytes of the buffer following the data may be leaked. Avoid this by extending all packets to ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be reproduced by running $ ping -s 11 destination • https://git.kernel.org/stable/c/9ad1a37493338cacf04e2c93acf44d151a7adda8 https://git.kernel.org/stable/c/f43190e33224c49e1c7ebbc25923ff400d87ec00 https://git.kernel.org/stable/c/34fcac26216ce17886af3eb392355b459367af1a https://git.kernel.org/stable/c/ce8eabc912fe9b9a62be1a5c6af5ad2196e90fc2 https://git.kernel.org/stable/c/cbd7ec083413c6a2e0c326d49e24ec7d12c7a9e0 •
CVSS: -EPSS: %CPEs: 4EXPL: 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/09af8b0ba70072be831f3ec459f4063d570f9e24 https://git.kernel.org/stable/c/af9ca9ca3e44f48b2a191e100d452fbf850c3d87 https://git.kernel.org/stable/c/d1a1dfcec77c57b1181da93d11a3db1bc4eefa97 https://git.kernel.org/stable/c/2a8787c1cdc7be24fdd8953ecd1a8743a1006235 •
CVSS: -EPSS: %CPEs: 4EXPL: 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/84175dc5b2c932266a50c04e5ce342c30f817a2f https://git.kernel.org/stable/c/eb7fc8b65cea22f9038c52398c8b22849e9620ea https://git.kernel.org/stable/c/e79050882b857c37634baedbdcf7c2047c24cbff https://git.kernel.org/stable/c/ea5ff5d351b520524019f7ff7f9ce418de2dad87 •
CVSS: -EPSS: %CPEs: 2EXPL: 0CVE-2024-46851 – drm/amd/display: Avoid race between dcn10_set_drr() and dc_state_destruct()
https://notcve.org/view.php?id=CVE-2024-46851
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, 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) • https://git.kernel.org/stable/c/06ad7e16425619a4a77154c2e85bededb3e04a4f https://git.kernel.org/stable/c/b6ce047a81f508f5c60756db8dfb5ff486e4dad0 https://git.kernel.org/stable/c/a7aeb03888b92304e2fc7d4d1c242f54a312561b •