Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: don&amp;#39;t set RO when shutting down f2fs<br /> <br /> Shutdown does not check the error of thaw_super due to readonly, which<br /> causes a deadlock like below.<br /> <br /> f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issue_discard_thread<br /> - bdev_freeze<br /> - freeze_super<br /> - f2fs_stop_checkpoint()<br /> - f2fs_handle_critical_error - sb_start_write<br /> - set RO - waiting<br /> - bdev_thaw<br /> - thaw_super_locked<br /> - return -EINVAL, if sb_rdonly()<br /> - f2fs_stop_discard_thread<br /> -&gt; wait for kthread_stop(discard_thread);

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: do not create EA inode under buffer lock<br /> <br /> ext4_xattr_set_entry() creates new EA inodes while holding buffer lock<br /> on the external xattr block. This is problematic as it nests all the<br /> allocation locking (which acquires locks on other buffers) under the<br /> buffer lock. This can even deadlock when the filesystem is corrupted and<br /> e.g. quota file is setup to contain xattr block as data block. Move the<br /> allocation of EA inode out of ext4_xattr_set_entry() into the callers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Avoid hw_desc array overrun in dw-axi-dmac<br /> <br /> I have a use case where nr_buffers = 3 and in which each descriptor is composed by 3<br /> segments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put()<br /> handles the hw_desc considering the descs_allocated, this scenario would result in a<br /> kernel panic (hw_desc array will be overrun).<br /> <br /> To fix this, the proposal is to add a new member to the axi_dma_desc structure,<br /> where we keep the number of allocated hw_descs (axi_desc_alloc()) and use it in<br /> axi_desc_put() to handle the hw_desc array correctly.<br /> <br /> Additionally I propose to remove the axi_chan_start_first_queued() call after completing<br /> the transfer, since it was identified that unbalance can occur (started descriptors can<br /> be interrupted and transfer ignored due to DMA channel not being enabled).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: remove clear SB_INLINECRYPT flag in default_options<br /> <br /> In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.<br /> If create new file or open file during this gap, these files<br /> will not use inlinecrypt. Worse case, it may lead to data<br /> corruption if wrappedkey_v0 is enable.<br /> <br /> Thread A: Thread B:<br /> <br /> -f2fs_remount -f2fs_file_open or f2fs_new_inode<br /> -default_options<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: Enforce hcall result buffer validity and size<br /> <br /> plpar_hcall(), plpar_hcall9(), and related functions expect callers to<br /> provide valid result buffers of certain minimum size. Currently this<br /> is communicated only through comments in the code and the compiler has<br /> no idea.<br /> <br /> For example, if I write a bug like this:<br /> <br /> long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE<br /> plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);<br /> <br /> This compiles with no diagnostics emitted, but likely results in stack<br /> corruption at runtime when plpar_hcall9() stores results past the end<br /> of the array. (To be clear this is a contrived example and I have not<br /> found a real instance yet.)<br /> <br /> To make this class of error less likely, we can use explicitly-sized<br /> array parameters instead of pointers in the declarations for the hcall<br /> APIs. When compiled with -Warray-bounds[1], the code above now<br /> provokes a diagnostic like this:<br /> <br /> error: array argument is too small;<br /> is of size 32, callee requires at least 72 [-Werror,-Warray-bounds]<br /> 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf,<br /> | ^ ~~~~~~<br /> <br /> [1] Enabled for LLVM builds but not GCC for now. See commit<br /> 0da6e5fd6c37 ("gcc: disable &amp;#39;-Warray-bounds&amp;#39; for gcc-13 too") and<br /> related changes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mtk-vcodec: potential null pointer deference in SCP<br /> <br /> The return value of devm_kzalloc() needs to be checked to avoid<br /> NULL pointer deference. This is similar to CVE-2022-3113.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_table_check: fix crash on ZONE_DEVICE<br /> <br /> Not all pages may apply to pgtable check. One example is ZONE_DEVICE<br /> pages: they map PFNs directly, and they don&amp;#39;t allocate page_ext at all<br /> even if there&amp;#39;s struct page around. One may reference<br /> devm_memremap_pages().<br /> <br /> When both ZONE_DEVICE and page-table-check enabled, then try to map some<br /> dax memories, one can trigger kernel bug constantly now when the kernel<br /> was trying to inject some pfn maps on the dax device:<br /> <br /> kernel BUG at mm/page_table_check.c:55!<br /> <br /> While it&amp;#39;s pretty legal to use set_pxx_at() for ZONE_DEVICE pages for page<br /> fault resolutions, skip all the checks if page_ext doesn&amp;#39;t even exist in<br /> pgtable checker, which applies to ZONE_DEVICE but maybe more.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: huge_memory: fix misused mapping_large_folio_support() for anon folios<br /> <br /> When I did a large folios split test, a WARNING "[ 5059.122759][ T166]<br /> Cannot split file folio to non-0 order" was triggered. But the test cases<br /> are only for anonmous folios. while mapping_large_folio_support() is only<br /> reasonable for page cache folios.<br /> <br /> In split_huge_page_to_list_to_order(), the folio passed to<br /> mapping_large_folio_support() maybe anonmous folio. The folio_test_anon()<br /> check is missing. So the split of the anonmous THP is failed. This is<br /> also the same for shmem_mapping(). We&amp;#39;d better add a check for both. But<br /> the shmem_mapping() in __split_huge_page() is not involved, as for<br /> anonmous folios, the end parameter is set to -1, so (head[i].index &gt;= end)<br /> is always false. shmem_mapping() is not called.<br /> <br /> Also add a VM_WARN_ON_ONCE() in mapping_large_folio_support() for anon<br /> mapping, So we can detect the wrong use more easily.<br /> <br /> THP folios maybe exist in the pagecache even the file system doesn&amp;#39;t<br /> support large folio, it is because when CONFIG_TRANSPARENT_HUGEPAGE is<br /> enabled, khugepaged will try to collapse read-only file-backed pages to<br /> THP. But the mapping does not actually support multi order large folios<br /> properly.<br /> <br /> Using /sys/kernel/debug/split_huge_pages to verify this, with this patch,<br /> large anon THP is successfully split and the warning is ceased.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix NULL pointer dereference in ocfs2_abort_trigger()<br /> <br /> bdev-&gt;bd_super has been removed and commit 8887b94d9322 change the usage<br /> from bdev-&gt;bd_super to b_assoc_map-&gt;host-&gt;i_sb. Since ocfs2 hasn&amp;#39;t set<br /> bh-&gt;b_assoc_map, it will trigger NULL pointer dereference when calling<br /> into ocfs2_abort_trigger().<br /> <br /> Actually this was pointed out in history, see commit 74e364ad1b13. But<br /> I&amp;#39;ve made a mistake when reviewing commit 8887b94d9322 and then<br /> re-introduce this regression.<br /> <br /> Since we cannot revive bdev in buffer head, so fix this issue by<br /> initializing all types of ocfs2 triggers when fill super, and then get the<br /> specific ocfs2 trigger from ocfs2_caching_info when access journal.<br /> <br /> [joseph.qi@linux.alibaba.com: v2]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix NULL pointer dereference in ocfs2_journal_dirty()<br /> <br /> bdev-&gt;bd_super has been removed and commit 8887b94d9322 change the usage<br /> from bdev-&gt;bd_super to b_assoc_map-&gt;host-&gt;i_sb. This introduces the<br /> following NULL pointer dereference in ocfs2_journal_dirty() since<br /> b_assoc_map is still not initialized. This can be easily reproduced by<br /> running xfstests generic/186, which simulate no more credits.<br /> <br /> [ 134.351592] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> [ 134.355341] RIP: 0010:ocfs2_journal_dirty+0x14f/0x160 [ocfs2]<br /> ...<br /> [ 134.365071] Call Trace:<br /> [ 134.365312] <br /> [ 134.365524] ? __die_body+0x1e/0x60<br /> [ 134.365868] ? page_fault_oops+0x13d/0x4f0<br /> [ 134.366265] ? __pfx_bit_wait_io+0x10/0x10<br /> [ 134.366659] ? schedule+0x27/0xb0<br /> [ 134.366981] ? exc_page_fault+0x6a/0x140<br /> [ 134.367356] ? asm_exc_page_fault+0x26/0x30<br /> [ 134.367762] ? ocfs2_journal_dirty+0x14f/0x160 [ocfs2]<br /> [ 134.368305] ? ocfs2_journal_dirty+0x13d/0x160 [ocfs2]<br /> [ 134.368837] ocfs2_create_new_meta_bhs.isra.51+0x139/0x2e0 [ocfs2]<br /> [ 134.369454] ocfs2_grow_tree+0x688/0x8a0 [ocfs2]<br /> [ 134.369927] ocfs2_split_and_insert.isra.67+0x35c/0x4a0 [ocfs2]<br /> [ 134.370521] ocfs2_split_extent+0x314/0x4d0 [ocfs2]<br /> [ 134.371019] ocfs2_change_extent_flag+0x174/0x410 [ocfs2]<br /> [ 134.371566] ocfs2_add_refcount_flag+0x3fa/0x630 [ocfs2]<br /> [ 134.372117] ocfs2_reflink_remap_extent+0x21b/0x4c0 [ocfs2]<br /> [ 134.372994] ? inode_update_timestamps+0x4a/0x120<br /> [ 134.373692] ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2]<br /> [ 134.374545] ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2]<br /> [ 134.375393] ocfs2_reflink_remap_blocks+0xe4/0x4e0 [ocfs2]<br /> [ 134.376197] ocfs2_remap_file_range+0x1de/0x390 [ocfs2]<br /> [ 134.376971] ? security_file_permission+0x29/0x50<br /> [ 134.377644] vfs_clone_file_range+0xfe/0x320<br /> [ 134.378268] ioctl_file_clone+0x45/0xa0<br /> [ 134.378853] do_vfs_ioctl+0x457/0x990<br /> [ 134.379422] __x64_sys_ioctl+0x6e/0xd0<br /> [ 134.379987] do_syscall_64+0x5d/0x170<br /> [ 134.380550] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 134.381231] RIP: 0033:0x7fa4926397cb<br /> [ 134.381786] Code: 73 01 c3 48 8b 0d bd 56 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8d 56 38 00 f7 d8 64 89 01 48<br /> [ 134.383930] RSP: 002b:00007ffc2b39f7b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> [ 134.384854] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fa4926397cb<br /> [ 134.385734] RDX: 00007ffc2b39f7f0 RSI: 000000004020940d RDI: 0000000000000003<br /> [ 134.386606] RBP: 0000000000000000 R08: 00111a82a4f015bb R09: 00007fa494221000<br /> [ 134.387476] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> [ 134.388342] R13: 0000000000f10000 R14: 0000558e844e2ac8 R15: 0000000000f10000<br /> [ 134.389207] <br /> <br /> Fix it by only aborting transaction and journal in ocfs2_journal_dirty()<br /> now, and leave ocfs2_abort() later when detecting an aborted handle,<br /> e.g. start next transaction. Also log the handle details in this case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists()<br /> <br /> We can trigger a slab-out-of-bounds with the following commands:<br /> <br /> mkfs.ext4 -F /dev/$disk 10G<br /> mount /dev/$disk /tmp/test<br /> echo 2147483647 &gt; /sys/fs/ext4/$disk/mb_group_prealloc<br /> echo test &gt; /tmp/test/file &amp;&amp; sync<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4]<br /> Read of size 8 at addr ffff888121b9d0f0 by task kworker/u2:0/11<br /> CPU: 0 PID: 11 Comm: kworker/u2:0 Tainted: GL 6.7.0-next-20240118 #521<br /> Call Trace:<br /> dump_stack_lvl+0x2c/0x50<br /> kasan_report+0xb6/0xf0<br /> ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4]<br /> ext4_mb_regular_allocator+0x19e9/0x2370 [ext4]<br /> ext4_mb_new_blocks+0x88a/0x1370 [ext4]<br /> ext4_ext_map_blocks+0x14f7/0x2390 [ext4]<br /> ext4_map_blocks+0x569/0xea0 [ext4]<br /> ext4_do_writepages+0x10f6/0x1bc0 [ext4]<br /> [...]<br /> ==================================================================<br /> <br /> The flow of issue triggering is as follows:<br /> <br /> // Set s_mb_group_prealloc to 2147483647 via sysfs<br /> ext4_mb_new_blocks<br /> ext4_mb_normalize_request<br /> ext4_mb_normalize_group_request<br /> ac-&gt;ac_g_ex.fe_len = EXT4_SB(sb)-&gt;s_mb_group_prealloc<br /> ext4_mb_regular_allocator<br /> ext4_mb_choose_next_group<br /> ext4_mb_choose_next_group_best_avail<br /> mb_avg_fragment_size_order<br /> order = fls(len) - 2 = 29<br /> ext4_mb_find_good_group_avg_frag_lists<br /> frag_list = &amp;sbi-&gt;s_mb_avg_fragment_size[order]<br /> if (list_empty(frag_list)) // Trigger SOOB!<br /> <br /> At 4k block size, the length of the s_mb_avg_fragment_size list is 14,<br /> but an oversized s_mb_group_prealloc is set, causing slab-out-of-bounds<br /> to be triggered by an attempt to access an element at index 29.<br /> <br /> Add a new attr_id attr_clusters_in_group with values in the range<br /> [0, sbi-&gt;s_clusters_per_group] and declare mb_group_prealloc as<br /> that type to fix the issue. In addition avoid returning an order<br /> from mb_avg_fragment_size_order() greater than MB_NUM_ORDERS(sb)<br /> and reduce some useless loops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()<br /> <br /> ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.<br /> <br /> syzbot reported:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024<br /> Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker<br /> RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64<br /> Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00<br /> RSP: 0018:ffffc90000117378 EFLAGS: 00010246<br /> RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7<br /> RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98<br /> RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000<br /> R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]<br /> xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]<br /> xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541<br /> xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835<br /> xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]<br /> xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201<br /> xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]<br /> xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309<br /> ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256<br /> send6+0x611/0xd20 drivers/net/wireguard/socket.c:139<br /> wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178<br /> wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200<br /> wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40<br /> wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51<br /> process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231<br /> process_scheduled_works kernel/workqueue.c:3312 [inline]<br /> worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393<br /> kthread+0x2c1/0x3a0 kernel/kthread.c:389<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244