CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-41070 – KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()
https://notcve.org/view.php?id=CVE-2024-41070
In the Linux kernel, the following vulnerability has been resolved: KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group() Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group(). It looks up `stt` from tablefd, but then continues to use it after doing fdput() on the returned fd. After the fdput() the tablefd is free to be closed by another thread. The close calls kvm_spapr_tce_release() and then release_spapr_tce_table() (via call_rcu()) which frees `stt`. Although there are calls to rcu_read_lock() in kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent the UAF, because `stt` is used outside the locked regions. With an artifcial delay after the fdput() and a userspace program which triggers the race, KASAN detects the UAF: BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505 CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1 Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Call Trace: dump_stack_lvl+0xb4/0x108 (unreliable) print_report+0x2b4/0x6ec kasan_report+0x118/0x2b0 __asan_load4+0xb8/0xd0 kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] kvm_vfio_set_attr+0x524/0xac0 [kvm] kvm_device_ioctl+0x144/0x240 [kvm] sys_ioctl+0x62c/0x1810 system_call_exception+0x190/0x440 system_call_vectored_common+0x15c/0x2ec ... Freed by task 0: ... kfree+0xec/0x3e0 release_spapr_tce_table+0xd4/0x11c [kvm] rcu_core+0x568/0x16a0 handle_softirqs+0x23c/0x920 do_softirq_own_stack+0x6c/0x90 do_softirq_own_stack+0x58/0x90 __irq_exit_rcu+0x218/0x2d0 irq_exit+0x30/0x80 arch_local_irq_restore+0x128/0x230 arch_local_irq_enable+0x1c/0x30 cpuidle_enter_state+0x134/0x5cc cpuidle_enter+0x6c/0xb0 call_cpuidle+0x7c/0x100 do_idle+0x394/0x410 cpu_startup_entry+0x60/0x70 start_secondary+0x3fc/0x410 start_secondary_prolog+0x10/0x14 Fix it by delaying the fdput() until `stt` is no longer in use, which is effectively the entire function. To keep the patch minimal add a call to fdput() at each of the existing return paths. Future work can convert the function to goto or __cleanup style cleanup. With the fix in place the test case no longer triggers the UAF. • https://git.kernel.org/stable/c/be847bb20c809de8ac124431b556f244400b0491 https://git.kernel.org/stable/c/4cdf6926f443c84f680213c7aafbe6f91a5fcbc0 https://git.kernel.org/stable/c/b26c8c85463ef27a522d24fcd05651f0bb039e47 https://git.kernel.org/stable/c/5f856023971f97fff74cfaf21b48ec320147b50a https://git.kernel.org/stable/c/82c7a4cf14aa866f8f7f09e662b02eddc49ee0bf https://git.kernel.org/stable/c/9975f93c760a32453d7639cf6fcf3f73b4e71ffe https://git.kernel.org/stable/c/a986fa57fd81a1430e00b3c6cf8a325d6f894a63 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41069 – ASoC: topology: Fix references to freed memory
https://notcve.org/view.php?id=CVE-2024-41069
In the Linux kernel, the following vulnerability has been resolved: ASoC: topology: Fix references to freed memory Most users after parsing a topology file, release memory used by it, so having pointer references directly into topology file contents is wrong. Use devm_kmemdup(), to allocate memory as needed. • https://git.kernel.org/stable/c/b188d7f3dfab10e332e3c1066e18857964a520d2 https://git.kernel.org/stable/c/ab5a6208b4d6872b1c6ecea1867940fc668cc76d https://git.kernel.org/stable/c/ccae5c6a1fab9494c86b7856faf05e296c617702 https://git.kernel.org/stable/c/97ab304ecd95c0b1703ff8c8c3956dc6e2afe8e1 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41068 – s390/sclp: Fix sclp_init() cleanup on failure
https://notcve.org/view.php?id=CVE-2024-41068
In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Fix sclp_init() cleanup on failure If sclp_init() fails it only partially cleans up: if there are multiple failing calls to sclp_init() sclp_state_change_event will be added several times to sclp_reg_list, which results in the following warning: ------------[ cut here ]------------ list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10. WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3 Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 ... Call Trace: [<000003ffe0d6076a>] __list_add_valid_or_report+0xe2/0xf8 ([<000003ffe0d60766>] __list_add_valid_or_report+0xde/0xf8) [<000003ffe0a8d37e>] sclp_init+0x40e/0x450 [<000003ffe00009f2>] do_one_initcall+0x42/0x1e0 [<000003ffe15b77a6>] do_initcalls+0x126/0x150 [<000003ffe15b7a0a>] kernel_init_freeable+0x1ba/0x1f8 [<000003ffe0d6650e>] kernel_init+0x2e/0x180 [<000003ffe000301c>] __ret_from_fork+0x3c/0x60 [<000003ffe0d759ca>] ret_from_fork+0xa/0x30 Fix this by removing sclp_state_change_event from sclp_reg_list when sclp_init() fails. • https://git.kernel.org/stable/c/a778987afc36d5dc02a1f82d352a81edcaf7eb83 https://git.kernel.org/stable/c/455a6653d8700a81aa8ed2b6442a3be476007090 https://git.kernel.org/stable/c/2e51db7ab71b89dc5a17068f5e201c69f13a4c9a https://git.kernel.org/stable/c/cf521049fcd07071ed42dc9758fce7d5ee120ec6 https://git.kernel.org/stable/c/79b4be70d5a160969b805f638ac5b4efd0aac7a3 https://git.kernel.org/stable/c/0a31b3fdc7e735c4f8c65fe4339945c717ed6808 https://git.kernel.org/stable/c/be0259796d0b76bbc7461e12c186814a9e58244c https://git.kernel.org/stable/c/6434b33faaa063df500af355ee6c3942e •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-41067 – btrfs: scrub: handle RST lookup error correctly
https://notcve.org/view.php?id=CVE-2024-41067
In the Linux kernel, the following vulnerability has been resolved: btrfs: scrub: handle RST lookup error correctly [BUG] When running btrfs/060 with forced RST feature, it would crash the following ASSERT() inside scrub_read_endio(): ASSERT(sector_nr < stripe->nr_sectors); Before that, we would have tree dump from btrfs_get_raid_extent_offset(), as we failed to find the RST entry for the range. [CAUSE] Inside scrub_submit_extent_sector_read() every time we allocated a new bbio we immediately called btrfs_map_block() to make sure there was some RST range covering the scrub target. But if btrfs_map_block() fails, we immediately call endio for the bbio, while the bbio is newly allocated, it's completely empty. Then inside scrub_read_endio(), we go through the bvecs to find the sector number (as bi_sector is no longer reliable if the bio is submitted to lower layers). And since the bio is empty, such bvecs iteration would not find any sector matching the sector, and return sector_nr == stripe->nr_sectors, triggering the ASSERT(). [FIX] Instead of calling btrfs_map_block() after allocating a new bbio, call btrfs_map_block() first. Since our only objective of calling btrfs_map_block() is only to update stripe_len, there is really no need to do that after btrfs_alloc_bio(). This new timing would avoid the problem of handling empty bbio completely, and in fact fixes a possible race window for the old code, where if the submission thread is the only owner of the pending_io, the scrub would never finish (since we didn't decrease the pending_io counter). Although the root cause of RST lookup failure still needs to be addressed. • https://git.kernel.org/stable/c/17d1fd302a53d7e456a7412da74be74a0cf63a72 https://git.kernel.org/stable/c/2c49908634a2b97b1c3abe0589be2739ac5e7fd5 •
CVSS: 6.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41066 – ibmvnic: Add tx check to prevent skb leak
https://notcve.org/view.php?id=CVE-2024-41066
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Add tx check to prevent skb leak Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] consumer_index^ tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null] The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT. Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems. • https://git.kernel.org/stable/c/16ad1557cae582e79bb82dddd612d9bdfaa11d4c https://git.kernel.org/stable/c/267c61c4afed0ff9a2e83462abad3f41d8ca1f06 https://git.kernel.org/stable/c/e7b75def33eae61ddaad6cb616c517dc3882eb2a https://git.kernel.org/stable/c/0983d288caf984de0202c66641577b739caad561 https://access.redhat.com/security/cve/CVE-2024-41066 https://bugzilla.redhat.com/show_bug.cgi?id=2300442 • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •