Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: scrub: handle RST lookup error correctly<br /> <br /> [BUG]<br /> When running btrfs/060 with forced RST feature, it would crash the<br /> following ASSERT() inside scrub_read_endio():<br /> <br /> ASSERT(sector_nr nr_sectors);<br /> <br /> Before that, we would have tree dump from<br /> btrfs_get_raid_extent_offset(), as we failed to find the RST entry for<br /> the range.<br /> <br /> [CAUSE]<br /> Inside scrub_submit_extent_sector_read() every time we allocated a new<br /> bbio we immediately called btrfs_map_block() to make sure there was some<br /> RST range covering the scrub target.<br /> <br /> But if btrfs_map_block() fails, we immediately call endio for the bbio,<br /> while the bbio is newly allocated, it&amp;#39;s completely empty.<br /> <br /> Then inside scrub_read_endio(), we go through the bvecs to find<br /> the sector number (as bi_sector is no longer reliable if the bio is<br /> submitted to lower layers).<br /> <br /> And since the bio is empty, such bvecs iteration would not find any<br /> sector matching the sector, and return sector_nr == stripe-&gt;nr_sectors,<br /> triggering the ASSERT().<br /> <br /> [FIX]<br /> Instead of calling btrfs_map_block() after allocating a new bbio, call<br /> btrfs_map_block() first.<br /> <br /> Since our only objective of calling btrfs_map_block() is only to update<br /> stripe_len, there is really no need to do that after btrfs_alloc_bio().<br /> <br /> This new timing would avoid the problem of handling empty bbio<br /> completely, and in fact fixes a possible race window for the old code,<br /> where if the submission thread is the only owner of the pending_io, the<br /> scrub would never finish (since we didn&amp;#39;t decrease the pending_io<br /> counter).<br /> <br /> Although the root cause of RST lookup failure still needs to be<br /> addressed.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: check bo_va-&gt;bo is non-NULL before using it<br /> <br /> The call to radeon_vm_clear_freed might clear bo_va-&gt;bo, so<br /> we have to check it before dereferencing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bluetooth/l2cap: sync sock recv cb and release<br /> <br /> The problem occurs between the system call to close the sock and hci_rx_work,<br /> where the former releases the sock and the latter accesses it without lock protection.<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> sock_close hci_rx_work<br /> l2cap_sock_release hci_acldata_packet<br /> l2cap_sock_kill l2cap_recv_frame<br /> sk_free l2cap_conless_channel<br /> l2cap_sock_recv_cb<br /> <br /> If hci_rx_work processes the data that needs to be received before the sock is<br /> closed, then everything is normal; Otherwise, the work thread may access the<br /> released sock when receiving data.<br /> <br /> Add a chan mutex in the rx callback of the sock to achieve synchronization between<br /> the sock release and recv cb.<br /> <br /> Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_core: cancel all works upon hci_unregister_dev()<br /> <br /> syzbot is reporting that calling hci_release_dev() from hci_error_reset()<br /> due to hci_dev_put() from hci_error_reset() can cause deadlock at<br /> destroy_workqueue(), for hci_error_reset() is called from<br /> hdev-&gt;req_workqueue which destroy_workqueue() needs to flush.<br /> <br /> We need to make sure that hdev-&gt;{rx_work,cmd_work,tx_work} which are<br /> queued into hdev-&gt;workqueue and hdev-&gt;{power_on,error_reset} which are<br /> queued into hdev-&gt;req_workqueue are no longer running by the moment<br /> <br /> destroy_workqueue(hdev-&gt;workqueue);<br /> destroy_workqueue(hdev-&gt;req_workqueue);<br /> <br /> are called from hci_release_dev().<br /> <br /> Call cancel_work_sync() on these work items from hci_unregister_dev()<br /> as soon as hdev-&gt;list is removed from hci_dev_list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/eeh: avoid possible crash when edev-&gt;pdev changes<br /> <br /> If a PCI device is removed during eeh_pe_report_edev(), edev-&gt;pdev<br /> will change and can cause a crash, hold the PCI rescan/remove lock<br /> while taking a copy of edev-&gt;pdev-&gt;bus.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: Whitelist dtl slub object for copying to userspace<br /> <br /> Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*<br /> results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as<br /> shown below.<br /> <br /> kernel BUG at mm/usercopy.c:102!<br /> Oops: Exception in kernel mode, sig: 5 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries<br /> Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc<br /> scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse<br /> CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85<br /> Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries<br /> NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8<br /> REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3)<br /> MSR: 8000000000029033 CR: 2828220f XER: 0000000e<br /> CFAR: c0000000001fdc80 IRQMASK: 0<br /> [ ... GPRs omitted ... ]<br /> NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0<br /> LR [c0000000005d23d0] usercopy_abort+0x74/0xb0<br /> Call Trace:<br /> usercopy_abort+0x74/0xb0 (unreliable)<br /> __check_heap_object+0xf8/0x120<br /> check_heap_object+0x218/0x240<br /> __check_object_size+0x84/0x1a4<br /> dtl_file_read+0x17c/0x2c4<br /> full_proxy_read+0x8c/0x110<br /> vfs_read+0xdc/0x3a0<br /> ksys_read+0x84/0x144<br /> system_call_exception+0x124/0x330<br /> system_call_vectored_common+0x15c/0x2ec<br /> --- interrupt: 3000 at 0x7fff81f3ab34<br /> <br /> Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")<br /> requires that only whitelisted areas in slab/slub objects can be copied to<br /> userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.<br /> Dtl contains hypervisor dispatch events which are expected to be read by<br /> privileged users. Hence mark this safe for user access.<br /> Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the<br /> entire object.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmvnic: Add tx check to prevent skb leak<br /> <br /> Below is a summary of how the driver stores a reference to an skb during<br /> transmit:<br /> tx_buff[free_map[consumer_index]]-&gt;skb = new_skb;<br /> free_map[consumer_index] = IBMVNIC_INVALID_MAP;<br /> consumer_index ++;<br /> Where variable data looks like this:<br /> free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]<br /> consumer_index^<br /> tx_buff == [skb=null, skb=, skb=, skb=null, skb=null]<br /> <br /> The driver has checks to ensure that free_map[consumer_index] pointed to<br /> a valid index but there was no check to ensure that this index pointed<br /> to an unused/null skb address. So, if, by some chance, our free_map and<br /> tx_buff lists become out of sync then we were previously risking an<br /> skb memory leak. This could then cause tcp congestion control to stop<br /> sending packets, eventually leading to ETIMEDOUT.<br /> <br /> Therefore, add a conditional to ensure that the skb address is null. If<br /> not then warn the user (because this is still a bug that should be<br /> patched) and free the old pointer to prevent memleak/tcp problems.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: topology: Fix references to freed memory<br /> <br /> Most users after parsing a topology file, release memory used by it, so<br /> having pointer references directly into topology file contents is wrong.<br /> Use devm_kmemdup(), to allocate memory as needed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()<br /> <br /> Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().<br /> <br /> It looks up `stt` from tablefd, but then continues to use it after doing<br /> fdput() on the returned fd. After the fdput() the tablefd is free to be<br /> closed by another thread. The close calls kvm_spapr_tce_release() and<br /> then release_spapr_tce_table() (via call_rcu()) which frees `stt`.<br /> <br /> Although there are calls to rcu_read_lock() in<br /> kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent<br /> the UAF, because `stt` is used outside the locked regions.<br /> <br /> With an artifcial delay after the fdput() and a userspace program which<br /> triggers the race, KASAN detects the UAF:<br /> <br /> BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]<br /> Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505<br /> CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1<br /> Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV<br /> Call Trace:<br /> dump_stack_lvl+0xb4/0x108 (unreliable)<br /> print_report+0x2b4/0x6ec<br /> kasan_report+0x118/0x2b0<br /> __asan_load4+0xb8/0xd0<br /> kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]<br /> kvm_vfio_set_attr+0x524/0xac0 [kvm]<br /> kvm_device_ioctl+0x144/0x240 [kvm]<br /> sys_ioctl+0x62c/0x1810<br /> system_call_exception+0x190/0x440<br /> system_call_vectored_common+0x15c/0x2ec<br /> ...<br /> Freed by task 0:<br /> ...<br /> kfree+0xec/0x3e0<br /> release_spapr_tce_table+0xd4/0x11c [kvm]<br /> rcu_core+0x568/0x16a0<br /> handle_softirqs+0x23c/0x920<br /> do_softirq_own_stack+0x6c/0x90<br /> do_softirq_own_stack+0x58/0x90<br /> __irq_exit_rcu+0x218/0x2d0<br /> irq_exit+0x30/0x80<br /> arch_local_irq_restore+0x128/0x230<br /> arch_local_irq_enable+0x1c/0x30<br /> cpuidle_enter_state+0x134/0x5cc<br /> cpuidle_enter+0x6c/0xb0<br /> call_cpuidle+0x7c/0x100<br /> do_idle+0x394/0x410<br /> cpu_startup_entry+0x60/0x70<br /> start_secondary+0x3fc/0x410<br /> start_secondary_prolog+0x10/0x14<br /> <br /> Fix it by delaying the fdput() until `stt` is no longer in use, which<br /> is effectively the entire function. To keep the patch minimal add a call<br /> to fdput() at each of the existing return paths. Future work can convert<br /> the function to goto or __cleanup style cleanup.<br /> <br /> With the fix in place the test case no longer triggers the UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: wext: add extra SIOCSIWSCAN data check<br /> <br /> In &amp;#39;cfg80211_wext_siwscan()&amp;#39;, add extra check whether number of<br /> channels passed via &amp;#39;ioctl(sock, SIOCSIWSCAN, ...)&amp;#39; doesn&amp;#39;t exceed<br /> IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/sclp: Fix sclp_init() cleanup on failure<br /> <br /> If sclp_init() fails it only partially cleans up: if there are multiple<br /> failing calls to sclp_init() sclp_state_change_event will be added several<br /> times to sclp_reg_list, which results in the following warning:<br /> <br /> ------------[ cut here ]------------<br /> list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.<br /> WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8<br /> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3<br /> Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8)<br /> 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<br /> ...<br /> Call Trace:<br /> [] __list_add_valid_or_report+0xe2/0xf8<br /> ([] __list_add_valid_or_report+0xde/0xf8)<br /> [] sclp_init+0x40e/0x450<br /> [] do_one_initcall+0x42/0x1e0<br /> [] do_initcalls+0x126/0x150<br /> [] kernel_init_freeable+0x1ba/0x1f8<br /> [] kernel_init+0x2e/0x180<br /> [] __ret_from_fork+0x3c/0x60<br /> [] ret_from_fork+0xa/0x30<br /> <br /> Fix this by removing sclp_state_change_event from sclp_reg_list when<br /> sclp_init() fails.