CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-49934 – fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name
https://notcve.org/view.php?id=CVE-2024-49934
In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? • https://git.kernel.org/stable/c/f92b8829c6e75632de4e2b9f70e7a7e6c5c2ba98 https://git.kernel.org/stable/c/ef921bc72328b577cb45772ff7921cba4773b74a https://git.kernel.org/stable/c/7f7b850689ac06a62befe26e1fd1806799e7f152 •
CVSS: -EPSS: %CPEs: 7EXPL: 0CVE-2024-49933 – blk_iocost: fix more out of bound shifts
https://notcve.org/view.php?id=CVE-2024-49933
In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: <IRQ> dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits. • https://git.kernel.org/stable/c/1f61d509257d6a05763d05bf37943b35306522b1 https://git.kernel.org/stable/c/f4ef9bef023d5c543cb0f3194ecacfd47ef590ec https://git.kernel.org/stable/c/59121bb38fdc01434ea3fe361ee02b59f036227f https://git.kernel.org/stable/c/1ab2cfe19700fb3dde4c7dfec392acff34db3120 https://git.kernel.org/stable/c/1b120f151871eb47ce9f283c007af3f8ae1d990e https://git.kernel.org/stable/c/364022095bdd4108efdaaa68576afa4712a5d085 https://git.kernel.org/stable/c/9bce8005ec0dcb23a58300e8522fe4a31da606fa •
CVSS: -EPSS: %CPEs: 2EXPL: 0CVE-2024-49932 – btrfs: don't readahead the relocation inode on RST
https://notcve.org/view.php?id=CVE-2024-49932
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: <TASK> ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? • https://git.kernel.org/stable/c/f7a1218a983ab98aba140dc20b25f60b39ee4033 https://git.kernel.org/stable/c/04915240e2c3a018e4c7f23418478d27226c8957 •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-49931 – wifi: ath12k: fix array out-of-bound access in SoC stats
https://notcve.org/view.php?id=CVE-2024-49931
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 • https://git.kernel.org/stable/c/d0e4274d9dc9f8409d56d622cd3ecf7b6fd49e2f https://git.kernel.org/stable/c/a4aef827a41cdaf6201bbaf773c1eae4e20e967b https://git.kernel.org/stable/c/ad791e3ec60cb66c1e4dc121ffbf872df312427d https://git.kernel.org/stable/c/e106b7ad13c1d246adaa57df73edb8f8b8acb240 •
CVSS: -EPSS: %CPEs: 7EXPL: 0CVE-2024-49930 – wifi: ath11k: fix array out-of-bound access in SoC stats
https://notcve.org/view.php?id=CVE-2024-49930
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 • https://git.kernel.org/stable/c/0f26f26944035ec67546a944f182cbad6577a9c0 https://git.kernel.org/stable/c/4dd732893bd38cec51f887244314e2b47f0d658f https://git.kernel.org/stable/c/73e235728e515faccc104b0153b47d0f263b3344 https://git.kernel.org/stable/c/7a552bc2f3efe2aaf77a85cb34cdf4a63d81a1a7 https://git.kernel.org/stable/c/6045ef5b4b00fee3629689f791992900a1c94009 https://git.kernel.org/stable/c/01b77f5ee11c89754fb836af8f76799d3b72ae2f https://git.kernel.org/stable/c/69f253e46af98af17e3efa3e5dfa72fcb7d1983d •