Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Clear affinity hint before calling ath12k_pci_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 /> ath12k_pci_msi_alloc(). This does no harm unless one of the functions<br /> requesting the IRQ fails and attempt to free the IRQ.<br /> <br /> This may end up with a warning from the IRQ core that is expecting the<br /> affinity hint to be cleared before freeing the IRQ:<br /> <br /> kernel/irq/manage.c:<br /> <br /> /* make sure affinity_hint is cleaned up */<br /> if (WARN_ON_ONCE(desc-&gt;affinity_hint))<br /> desc-&gt;affinity_hint = NULL;<br /> <br /> So to fix this issue, clear the IRQ affinity hint before calling<br /> ath12k_pci_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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix potential deadloop in prepare_compress_overwrite()<br /> <br /> Jan Prusakowski reported a kernel hang issue as below:<br /> <br /> When running xfstests on linux-next kernel (6.14.0-rc3, 6.12) I<br /> encountered a problem in generic/475 test where fsstress process<br /> gets blocked in __f2fs_write_data_pages() and the test hangs.<br /> The options I used are:<br /> <br /> MKFS_OPTIONS -- -O compression -O extra_attr -O project_quota -O quota /dev/vdc<br /> MOUNT_OPTIONS -- -o acl,user_xattr -o discard,compress_extension=* /dev/vdc /vdc<br /> <br /> INFO: task kworker/u8:0:11 blocked for more than 122 seconds.<br /> Not tainted 6.14.0-rc3-xfstests-lockdep #1<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kworker/u8:0 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208160 flags:0x00004000<br /> Workqueue: writeback wb_workfn (flush-253:0)<br /> Call Trace:<br /> <br /> __schedule+0x309/0x8e0<br /> schedule+0x3a/0x100<br /> schedule_preempt_disabled+0x15/0x30<br /> __mutex_lock+0x59a/0xdb0<br /> __f2fs_write_data_pages+0x3ac/0x400<br /> do_writepages+0xe8/0x290<br /> __writeback_single_inode+0x5c/0x360<br /> writeback_sb_inodes+0x22f/0x570<br /> wb_writeback+0xb0/0x410<br /> wb_do_writeback+0x47/0x2f0<br /> wb_workfn+0x5a/0x1c0<br /> process_one_work+0x223/0x5b0<br /> worker_thread+0x1d5/0x3c0<br /> kthread+0xfd/0x230<br /> ret_from_fork+0x31/0x50<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> The root cause is: once generic/475 starts toload error table to dm<br /> device, f2fs_prepare_compress_overwrite() will loop reading compressed<br /> cluster pages due to IO error, meanwhile it has held .writepages lock,<br /> it can block all other writeback tasks.<br /> <br /> Let&amp;#39;s fix this issue w/ below changes:<br /> - add f2fs_handle_page_eio() in prepare_compress_overwrite() to<br /> detect IO error.<br /> - detect cp_error earler in f2fs_read_multi_pages().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid1,raid10: don&amp;#39;t ignore IO flags<br /> <br /> If blk-wbt is enabled by default, it&amp;#39;s found that raid write performance<br /> is quite bad because all IO are throttled by wbt of underlying disks,<br /> due to flag REQ_IDLE is ignored. And turns out this behaviour exist since<br /> blk-wbt is introduced.<br /> <br /> Other than REQ_IDLE, other flags should not be ignored as well, for<br /> example REQ_META can be set for filesystems, clearing it can cause priority<br /> reverse problems; And REQ_NOWAIT should not be cleared as well, because<br /> io will wait instead of failing directly in underlying disks.<br /> <br /> Fix those problems by keep IO flags from master bio.<br /> <br /> Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT")