Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watch_queue: fix pipe accounting mismatch<br /> <br /> Currently, watch_queue_set_size() modifies the pipe buffers charged to<br /> user-&gt;pipe_bufs without updating the pipe-&gt;nr_accounted on the pipe<br /> itself, due to the if (!pipe_has_watch_queue()) test in<br /> pipe_resize_ring(). This means that when the pipe is ultimately freed,<br /> we decrement user-&gt;pipe_bufs by something other than what than we had<br /> charged to it, potentially leading to an underflow. This in turn can<br /> cause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM.<br /> <br /> To remedy this, explicitly account for the pipe usage in<br /> watch_queue_set_size() to match the number set via account_pipe_buffers()<br /> <br /> (It&amp;#39;s unclear why watch_queue_set_size() does not update nr_accounted;<br /> it may be due to intentional overprovisioning in watch_queue_set_size()?)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: timer: Don&amp;#39;t take register_mutex with copy_from/to_user()<br /> <br /> The infamous mmap_lock taken in copy_from/to_user() can be often<br /> problematic when it&amp;#39;s called inside another mutex, as they might lead<br /> to deadlocks.<br /> <br /> In the case of ALSA timer code, the bad pattern is with<br /> guard(mutex)(&amp;register_mutex) that covers copy_from/to_user() -- which<br /> was mistakenly introduced at converting to guard(), and it had been<br /> carefully worked around in the past.<br /> <br /> This patch fixes those pieces simply by moving copy_from/to_user() out<br /> of the register mutex lock again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RISC-V: KVM: Teardown riscv specific bits after kvm_exit<br /> <br /> During a module removal, kvm_exit invokes arch specific disable<br /> call which disables AIA. However, we invoke aia_exit before kvm_exit<br /> resulting in the following warning. KVM kernel module can&amp;#39;t be inserted<br /> afterwards due to inconsistent state of IRQ.<br /> <br /> [25469.031389] percpu IRQ 31 still enabled on CPU0!<br /> [25469.031732] WARNING: CPU: 3 PID: 943 at kernel/irq/manage.c:2476 __free_percpu_irq+0xa2/0x150<br /> [25469.031804] Modules linked in: kvm(-)<br /> [25469.031848] CPU: 3 UID: 0 PID: 943 Comm: rmmod Not tainted 6.14.0-rc5-06947-g91c763118f47-dirty #2<br /> [25469.031905] Hardware name: riscv-virtio,qemu (DT)<br /> [25469.031928] epc : __free_percpu_irq+0xa2/0x150<br /> [25469.031976] ra : __free_percpu_irq+0xa2/0x150<br /> [25469.032197] epc : ffffffff8007db1e ra : ffffffff8007db1e sp : ff2000000088bd50<br /> [25469.032241] gp : ffffffff8131cef8 tp : ff60000080b96400 t0 : ff2000000088baf8<br /> [25469.032285] t1 : fffffffffffffffc t2 : 5249207570637265 s0 : ff2000000088bd90<br /> [25469.032329] s1 : ff60000098b21080 a0 : 037d527a15eb4f00 a1 : 037d527a15eb4f00<br /> [25469.032372] a2 : 0000000000000023 a3 : 0000000000000001 a4 : ffffffff8122dbf8<br /> [25469.032410] a5 : 0000000000000fff a6 : 0000000000000000 a7 : ffffffff8122dc10<br /> [25469.032448] s2 : ff60000080c22eb0 s3 : 0000000200000022 s4 : 000000000000001f<br /> [25469.032488] s5 : ff60000080c22e00 s6 : ffffffff80c351c0 s7 : 0000000000000000<br /> [25469.032582] s8 : 0000000000000003 s9 : 000055556b7fb490 s10: 00007ffff0e12fa0<br /> [25469.032621] s11: 00007ffff0e13e9a t3 : ffffffff81354ac7 t4 : ffffffff81354ac7<br /> [25469.032664] t5 : ffffffff81354ac8 t6 : ffffffff81354ac7<br /> [25469.032698] status: 0000000200000100 badaddr: ffffffff8007db1e cause: 0000000000000003<br /> [25469.032738] [] __free_percpu_irq+0xa2/0x150<br /> [25469.032797] [] free_percpu_irq+0x30/0x5e<br /> [25469.032856] [] kvm_riscv_aia_exit+0x40/0x42 [kvm]<br /> [25469.033947] [] cleanup_module+0x10/0x32 [kvm]<br /> [25469.035300] [] __riscv_sys_delete_module+0x18e/0x1fc<br /> [25469.035374] [] syscall_handler+0x3a/0x46<br /> [25469.035456] [] do_trap_ecall_u+0x72/0x134<br /> [25469.035536] [] handle_exception+0x148/0x156<br /> <br /> Invoke aia_exit and other arch specific cleanup functions after kvm_exit<br /> so that disable gets a chance to be called first before exit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: update channel list in reg notifier instead reg worker<br /> <br /> Currently when ath11k gets a new channel list, it will be processed<br /> according to the following steps:<br /> 1. update new channel list to cfg80211 and queue reg_work.<br /> 2. cfg80211 handles new channel list during reg_work.<br /> 3. update cfg80211&amp;#39;s handled channel list to firmware by<br /> ath11k_reg_update_chan_list().<br /> <br /> But ath11k will immediately execute step 3 after reg_work is just<br /> queued. Since step 2 is asynchronous, cfg80211 may not have completed<br /> handling the new channel list, which may leading to an out-of-bounds<br /> write error:<br /> BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list<br /> Call Trace:<br /> ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k]<br /> kfree+0x109/0x3a0<br /> ath11k_regd_update+0x1cf/0x350 [ath11k]<br /> ath11k_regd_update_work+0x14/0x20 [ath11k]<br /> process_one_work+0xe35/0x14c0<br /> <br /> Should ensure step 2 is completely done before executing step 3. Thus<br /> Wen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set,<br /> cfg80211 will notify ath11k after step 2 is done.<br /> <br /> So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will<br /> notify ath11k after step 2 is done. At this time, there will be no<br /> KASAN bug during the execution of the step 3.<br /> <br /> [1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/<br /> <br /> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: quota: fix to avoid warning in dquot_writeback_dquots()<br /> <br /> F2FS-fs (dm-59): checkpoint=enable has some unwritten data.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 6 PID: 8013 at fs/quota/dquot.c:691 dquot_writeback_dquots+0x2fc/0x308<br /> pc : dquot_writeback_dquots+0x2fc/0x308<br /> lr : f2fs_quota_sync+0xcc/0x1c4<br /> Call trace:<br /> dquot_writeback_dquots+0x2fc/0x308<br /> f2fs_quota_sync+0xcc/0x1c4<br /> f2fs_write_checkpoint+0x3d4/0x9b0<br /> f2fs_issue_checkpoint+0x1bc/0x2c0<br /> f2fs_sync_fs+0x54/0x150<br /> f2fs_do_sync_file+0x2f8/0x814<br /> __f2fs_ioctl+0x1960/0x3244<br /> f2fs_ioctl+0x54/0xe0<br /> __arm64_sys_ioctl+0xa8/0xe4<br /> invoke_syscall+0x58/0x114<br /> <br /> checkpoint and f2fs_remount may race as below, resulting triggering warning<br /> in dquot_writeback_dquots().<br /> <br /> atomic write remount<br /> - do_remount<br /> - down_write(&amp;sb-&gt;s_umount);<br /> - f2fs_remount<br /> - ioctl<br /> - f2fs_do_sync_file<br /> - f2fs_sync_fs<br /> - f2fs_write_checkpoint<br /> - block_operations<br /> - locked = down_read_trylock(&amp;sbi-&gt;sb-&gt;s_umount)<br /> : fail to lock due to the write lock was held by remount<br /> - up_write(&amp;sb-&gt;s_umount);<br /> - f2fs_quota_sync<br /> - dquot_writeback_dquots<br /> - WARN_ON_ONCE(!rwsem_is_locked(&amp;sb-&gt;s_umount))<br /> : trigger warning because s_umount lock was unlocked by remount<br /> <br /> If checkpoint comes from mount/umount/remount/freeze/quotactl, caller of<br /> checkpoint has already held s_umount lock, calling dquot_writeback_dquots()<br /> in the context should be safe.<br /> <br /> So let&amp;#39;s record task to sbi-&gt;umount_lock_holder, so that checkpoint can<br /> know whether the lock has held in the context or not by checking current<br /> w/ it.<br /> <br /> In addition, in order to not misrepresent caller of checkpoint, we should<br /> not allow to trigger async checkpoint for those callers: mount/umount/remount/<br /> freeze/quotactl.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dlm: prevent NPD when writing a positive value to event_done<br /> <br /> do_uevent returns the value written to event_done. In case it is a<br /> positive value, new_lockspace would undo all the work, and lockspace<br /> would not be set. __dlm_new_lockspace, however, would treat that<br /> positive value as a success due to commit 8511a2728ab8 ("dlm: fix use<br /> count with multiple joins").<br /> <br /> Down the line, device_create_lockspace would pass that NULL lockspace to<br /> dlm_find_lockspace_local, leading to a NULL pointer dereference.<br /> <br /> Treating such positive values as successes prevents the problem. Given<br /> this has been broken for so long, this is unlikely to break userspace<br /> expectations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid panic once fallocation fails for pinfile<br /> <br /> syzbot reports a f2fs bug as below:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/segment.c:2746!<br /> CPU: 0 UID: 0 PID: 5323 Comm: syz.0.0 Not tainted 6.13.0-rc2-syzkaller-00018-g7cb1b4663150 #0<br /> RIP: 0010:get_new_segment fs/f2fs/segment.c:2746 [inline]<br /> RIP: 0010:new_curseg+0x1f52/0x1f70 fs/f2fs/segment.c:2876<br /> Call Trace:<br /> <br /> __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3210<br /> f2fs_allocate_new_section fs/f2fs/segment.c:3224 [inline]<br /> f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3238<br /> f2fs_expand_inode_data+0x696/0xca0 fs/f2fs/file.c:1830<br /> f2fs_fallocate+0x537/0xa10 fs/f2fs/file.c:1940<br /> vfs_fallocate+0x569/0x6e0 fs/open.c:327<br /> do_vfs_ioctl+0x258c/0x2e40 fs/ioctl.c:885<br /> __do_sys_ioctl fs/ioctl.c:904 [inline]<br /> __se_sys_ioctl+0x80/0x170 fs/ioctl.c:892<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Concurrent pinfile allocation may run out of free section, result in<br /> panic in get_new_segment(), let&amp;#39;s expand pin_sem lock coverage to<br /> include f2fs_gc(), so that we can make sure to reclaim enough free<br /> space for following allocation.<br /> <br /> In addition, do below changes to enhance error path handling:<br /> - call f2fs_bug_on() only in non-pinfile allocation path in<br /> get_new_segment().<br /> - call reset_curseg_fields() to reset all fields of curseg in<br /> new_curseg()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: int340x: Add NULL check for adev<br /> <br /> Not all devices have an ACPI companion fwnode, so adev might be NULL.<br /> This is similar to the commit cd2fd6eab480<br /> ("platform/x86: int3472: Check for adev == NULL").<br /> <br /> Add a check for adev not being set and return -ENODEV in that case to<br /> avoid a possible NULL pointer deref in int3402_thermal_probe().<br /> <br /> Note, under the same directory, int3400_thermal_probe() has such a<br /> check.<br /> <br /> [ rjw: Subject edit, added Fixes: ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path<br /> <br /> If a shared IRQ is used by the driver due to platform limitation, then the<br /> IRQ affinity hint is set right after the allocation of IRQ vectors in<br /> ath11k_pci_alloc_msi(). This does no harm unless one of the functions<br /> requesting the IRQ fails and attempt to free the IRQ. This results in the<br /> below warning:<br /> <br /> WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c<br /> Call trace:<br /> free_irq+0x278/0x29c<br /> ath11k_pcic_free_irq+0x70/0x10c [ath11k]<br /> ath11k_pci_probe+0x800/0x820 [ath11k_pci]<br /> local_pci_probe+0x40/0xbc<br /> <br /> The warning is due to not clearing the affinity hint before freeing the<br /> IRQs.<br /> <br /> So to fix this issue, clear the IRQ affinity hint before calling<br /> ath11k_pcic_free_irq() in the error path. The affinity will be cleared once<br /> again further down the error path due to code organization, but that does<br /> no harm.<br /> <br /> Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()<br /> <br /> There&amp;#39;s issue as follows:<br /> BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790<br /> Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172<br /> <br /> CPU: 3 PID: 15172 Comm: syz-executor.0<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:82 [inline]<br /> dump_stack+0xbe/0xfd lib/dump_stack.c:123<br /> print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400<br /> __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560<br /> kasan_report+0x3a/0x50 mm/kasan/report.c:585<br /> ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137<br /> ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896<br /> ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323<br /> evict+0x39f/0x880 fs/inode.c:622<br /> iput_final fs/inode.c:1746 [inline]<br /> iput fs/inode.c:1772 [inline]<br /> iput+0x525/0x6c0 fs/inode.c:1758<br /> ext4_orphan_cleanup fs/ext4/super.c:3298 [inline]<br /> ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300<br /> mount_bdev+0x355/0x410 fs/super.c:1446<br /> legacy_get_tree+0xfe/0x220 fs/fs_context.c:611<br /> vfs_get_tree+0x8d/0x2f0 fs/super.c:1576<br /> do_new_mount fs/namespace.c:2983 [inline]<br /> path_mount+0x119a/0x1ad0 fs/namespace.c:3316<br /> do_mount+0xfc/0x110 fs/namespace.c:3329<br /> __do_sys_mount fs/namespace.c:3540 [inline]<br /> __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514<br /> do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46<br /> entry_SYSCALL_64_after_hwframe+0x67/0xd1<br /> <br /> Memory state around the buggy address:<br /> ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ^<br /> ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> <br /> Above issue happens as ext4_xattr_delete_inode() isn&amp;#39;t check xattr<br /> is valid if xattr is in inode.<br /> To solve above issue call xattr_check_inode() check if xattr if valid<br /> in inode. In fact, we can directly verify in ext4_iget_extra_inode(),<br /> so that there is no divergent verification.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: validate queue quanta parameters to prevent OOB access<br /> <br /> Add queue wraparound prevention in quanta configuration.<br /> Ensure end_qid does not overflow by validating start_qid and num_queues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: fix mddev uaf while iterating all_mddevs list<br /> <br /> While iterating all_mddevs list from md_notify_reboot() and md_exit(),<br /> list_for_each_entry_safe is used, and this can race with deletint the<br /> next mddev, causing UAF:<br /> <br /> t1:<br /> spin_lock<br /> //list_for_each_entry_safe(mddev, n, ...)<br /> mddev_get(mddev1)<br /> // assume mddev2 is the next entry<br /> spin_unlock<br /> t2:<br /> //remove mddev2<br /> ...<br /> mddev_free<br /> spin_lock<br /> list_del<br /> spin_unlock<br /> kfree(mddev2)<br /> mddev_put(mddev1)<br /> spin_lock<br /> //continue dereference mddev2-&gt;all_mddevs<br /> <br /> The old helper for_each_mddev() actually grab the reference of mddev2<br /> while holding the lock, to prevent from being freed. This problem can be<br /> fixed the same way, however, the code will be complex.<br /> <br /> Hence switch to use list_for_each_entry, in this case mddev_put() can free<br /> the mddev1 and it&amp;#39;s not safe as well. Refer to md_seq_show(), also factor<br /> out a helper mddev_put_locked() to fix this problem.