Vulnerabilities

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/md-bitmap: fix wrong bitmap_limit for clustermd when write sb<br /> <br /> In clustermd, separate write-intent-bitmaps are used for each cluster<br /> node:<br /> <br /> 0 4k 8k 12k<br /> -------------------------------------------------------------------<br /> | idle | md super | bm super [0] + bits |<br /> | bm bits[0, contd] | bm super[1] + bits | bm bits[1, contd] |<br /> | bm super[2] + bits | bm bits [2, contd] | bm super[3] + bits |<br /> | bm bits [3, contd] | | |<br /> <br /> So in node 1, pg_index in __write_sb_page() could equal to<br /> bitmap-&gt;storage.file_pages. Then bitmap_limit will be calculated to<br /> 0. md_super_write() will be called with 0 size.<br /> That means the first 4k sb area of node 1 will never be updated<br /> through filemap_write_page().<br /> This bug causes hang of mdadm/clustermd_tests/01r1_Grow_resize.<br /> <br /> Here use (pg_index % bitmap-&gt;storage.file_pages) to make calculation<br /> of bitmap_limit correct.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid accessing uninitialized curseg<br /> <br /> syzbot reports a f2fs bug as below:<br /> <br /> F2FS-fs (loop3): Stopped filesystem due to reason: 7<br /> kworker/u8:7: attempt to access beyond end of device<br /> BUG: unable to handle page fault for address: ffffed1604ea3dfa<br /> RIP: 0010:get_ckpt_valid_blocks fs/f2fs/segment.h:361 [inline]<br /> RIP: 0010:has_curseg_enough_space fs/f2fs/segment.h:570 [inline]<br /> RIP: 0010:__get_secs_required fs/f2fs/segment.h:620 [inline]<br /> RIP: 0010:has_not_enough_free_secs fs/f2fs/segment.h:633 [inline]<br /> RIP: 0010:has_enough_free_secs+0x575/0x1660 fs/f2fs/segment.h:649<br /> <br /> f2fs_is_checkpoint_ready fs/f2fs/segment.h:671 [inline]<br /> f2fs_write_inode+0x425/0x540 fs/f2fs/inode.c:791<br /> write_inode fs/fs-writeback.c:1525 [inline]<br /> __writeback_single_inode+0x708/0x10d0 fs/fs-writeback.c:1745<br /> writeback_sb_inodes+0x820/0x1360 fs/fs-writeback.c:1976<br /> wb_writeback+0x413/0xb80 fs/fs-writeback.c:2156<br /> wb_do_writeback fs/fs-writeback.c:2303 [inline]<br /> wb_workfn+0x410/0x1080 fs/fs-writeback.c:2343<br /> process_one_work kernel/workqueue.c:3236 [inline]<br /> process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317<br /> worker_thread+0x870/0xd30 kernel/workqueue.c:3398<br /> kthread+0x7a9/0x920 kernel/kthread.c:464<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> Commit 8b10d3653735 ("f2fs: introduce FAULT_NO_SEGMENT") allows to trigger<br /> no free segment fault in allocator, then it will update curseg-&gt;segno to<br /> NULL_SEGNO, though, CP_ERROR_FLAG has been set, f2fs_write_inode() missed<br /> to check the flag, and access invalid curseg-&gt;segno directly in below call<br /> path, then resulting in panic:<br /> <br /> - f2fs_write_inode<br /> - f2fs_is_checkpoint_ready<br /> - has_enough_free_secs<br /> - has_not_enough_free_secs<br /> - __get_secs_required<br /> - has_curseg_enough_space<br /> - get_ckpt_valid_blocks<br /> : access invalid curseg-&gt;segno<br /> <br /> To avoid this issue, let&amp;#39;s:<br /> - check CP_ERROR_FLAG flag in prior to f2fs_is_checkpoint_ready() in<br /> f2fs_write_inode().<br /> - in has_curseg_enough_space(), save curseg-&gt;segno into a temp variable,<br /> and verify its validation before use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix adding folio to bio<br /> <br /> &gt;4GB folio is possible on some ARCHs, such as aarch64, 16GB hugepage<br /> is supported, then &amp;#39;offset&amp;#39; of folio can&amp;#39;t be held in &amp;#39;unsigned int&amp;#39;,<br /> cause warning in bio_add_folio_nofail() and IO failure.<br /> <br /> Fix it by adjusting &amp;#39;page&amp;#39; &amp; trimming &amp;#39;offset&amp;#39; so that `-&gt;bi_offset` won&amp;#39;t<br /> be overflow, and folio can be added to bio successfully.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: goto right label &amp;#39;out_mmap_sem&amp;#39; in ext4_setattr()<br /> <br /> Otherwise, if ext4_inode_attach_jinode() fails, a hung task will<br /> happen because filemap_invalidate_unlock() isn&amp;#39;t called to unlock<br /> mapping-&gt;invalidate_lock. Like this:<br /> <br /> EXT4-fs error (device sda) in ext4_setattr:5557: Out of memory<br /> INFO: task fsstress:374 blocked for more than 122 seconds.<br /> Not tainted 6.14.0-rc1-next-20250206-xfstests-dirty #726<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:fsstress state:D stack:0 pid:374 tgid:374 ppid:373<br /> task_flags:0x440140 flags:0x00000000<br /> Call Trace:<br /> <br /> __schedule+0x2c9/0x7f0<br /> schedule+0x27/0xa0<br /> schedule_preempt_disabled+0x15/0x30<br /> rwsem_down_read_slowpath+0x278/0x4c0<br /> down_read+0x59/0xb0<br /> page_cache_ra_unbounded+0x65/0x1b0<br /> filemap_get_pages+0x124/0x3e0<br /> filemap_read+0x114/0x3d0<br /> vfs_read+0x297/0x360<br /> ksys_read+0x6c/0xe0<br /> do_syscall_64+0x4b/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: init wiphy_work before allocating rfkill fails<br /> <br /> syzbort reported a uninitialize wiphy_work_lock in cfg80211_dev_free. [1]<br /> <br /> After rfkill allocation fails, the wiphy release process will be performed,<br /> which will cause cfg80211_dev_free to access the uninitialized wiphy_work<br /> related data.<br /> <br /> Move the initialization of wiphy_work to before rfkill initialization to<br /> avoid this issue.<br /> <br /> [1]<br /> INFO: trying to register non-static key.<br /> The code is fine but needs lockdep annotation, or maybe<br /> you didn&amp;#39;t initialize this object before use?<br /> turning off the locking correctness validator.<br /> CPU: 0 UID: 0 PID: 5935 Comm: syz-executor550 Not tainted 6.14.0-rc6-syzkaller-00103-g4003c9e78778 #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br /> assign_lock_key kernel/locking/lockdep.c:983 [inline]<br /> register_lock_class+0xc39/0x1240 kernel/locking/lockdep.c:1297<br /> __lock_acquire+0x135/0x3c40 kernel/locking/lockdep.c:5103<br /> lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5851<br /> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]<br /> _raw_spin_lock_irqsave+0x3a/0x60 kernel/locking/spinlock.c:162<br /> cfg80211_dev_free+0x30/0x3d0 net/wireless/core.c:1196<br /> device_release+0xa1/0x240 drivers/base/core.c:2568<br /> kobject_cleanup lib/kobject.c:689 [inline]<br /> kobject_release lib/kobject.c:720 [inline]<br /> kref_put include/linux/kref.h:65 [inline]<br /> kobject_put+0x1e4/0x5a0 lib/kobject.c:737<br /> put_device+0x1f/0x30 drivers/base/core.c:3774<br /> wiphy_free net/wireless/core.c:1224 [inline]<br /> wiphy_new_nm+0x1c1f/0x2160 net/wireless/core.c:562<br /> ieee80211_alloc_hw_nm+0x1b7a/0x2260 net/mac80211/main.c:835<br /> mac80211_hwsim_new_radio+0x1d6/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5185<br /> hwsim_new_radio_nl+0xb42/0x12b0 drivers/net/wireless/virtual/mac80211_hwsim.c:6242<br /> genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115<br /> genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]<br /> genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210<br /> netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2533<br /> genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]<br /> netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1338<br /> netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1882<br /> sock_sendmsg_nosec net/socket.c:718 [inline]<br /> __sock_sendmsg net/socket.c:733 [inline]<br /> ____sys_sendmsg+0xaaf/0xc90 net/socket.c:2573<br /> ___sys_sendmsg+0x135/0x1e0 net/socket.c:2627<br /> __sys_sendmsg+0x16e/0x220 net/socket.c:2659<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83<br /> <br /> Close: https://syzkaller.appspot.com/bug?extid=aaf0488c83d1d5f4f029

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")