Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/type1: fix cap_migration information leak<br /> <br /> Fix an information leak where an uninitialized hole in struct<br /> vfio_iommu_type1_info_cap_migration on the stack is exposed to userspace.<br /> <br /> The definition of struct vfio_iommu_type1_info_cap_migration contains a hole as<br /> shown in this pahole(1) output:<br /> <br /> struct vfio_iommu_type1_info_cap_migration {<br /> struct vfio_info_cap_header header; /* 0 8 */<br /> __u32 flags; /* 8 4 */<br /> <br /> /* XXX 4 bytes hole, try to pack */<br /> <br /> __u64 pgsize_bitmap; /* 16 8 */<br /> __u64 max_dirty_bitmap_size; /* 24 8 */<br /> <br /> /* size: 32, cachelines: 1, members: 4 */<br /> /* sum members: 28, holes: 1, sum holes: 4 */<br /> /* last cacheline: 32 bytes */<br /> };<br /> <br /> The cap_mig variable is filled in without initializing the hole:<br /> <br /> static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu,<br /> struct vfio_info_cap *caps)<br /> {<br /> struct vfio_iommu_type1_info_cap_migration cap_mig;<br /> <br /> cap_mig.header.id = VFIO_IOMMU_TYPE1_INFO_CAP_MIGRATION;<br /> cap_mig.header.version = 1;<br /> <br /> cap_mig.flags = 0;<br /> /* support minimum pgsize */<br /> cap_mig.pgsize_bitmap = (size_t)1 id, cap-&gt;version);<br /> if (IS_ERR(header))<br /> return PTR_ERR(header);<br /> <br /> memcpy(header + 1, cap + 1, size - sizeof(*header));<br /> <br /> return 0;<br /> }<br /> <br /> This issue was found by code inspection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: fix NULL-deref on irq uninstall<br /> <br /> In case of early initialisation errors and on platforms that do not use<br /> the DPU controller, the deinitilisation code can be called with the kms<br /> pointer set to NULL.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/525104/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/user_events: Ensure write index cannot be negative<br /> <br /> The write index indicates which event the data is for and accesses a<br /> per-file array. The index is passed by user processes during write()<br /> calls as the first 4 bytes. Ensure that it cannot be negative by<br /> returning -EINVAL to prevent out of bounds accesses.<br /> <br /> Update ftrace self-test to ensure this occurs properly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix WARNING in mark_buffer_dirty due to discarded buffer reuse<br /> <br /> A syzbot stress test using a corrupted disk image reported that<br /> mark_buffer_dirty() called from __nilfs_mark_inode_dirty() or<br /> nilfs_palloc_commit_alloc_entry() may output a kernel warning, and can<br /> panic if the kernel is booted with panic_on_warn.<br /> <br /> This is because nilfs2 keeps buffer pointers in local structures for some<br /> metadata and reuses them, but such buffers may be forcibly discarded by<br /> nilfs_clear_dirty_page() in some critical situations.<br /> <br /> This issue is reported to appear after commit 28a65b49eb53 ("nilfs2: do<br /> not write dirty data after degenerating to read-only"), but the issue has<br /> potentially existed before.<br /> <br /> Fix this issue by checking the uptodate flag when attempting to reuse an<br /> internally held buffer, and reloading the metadata instead of reusing the<br /> buffer if the flag was lost.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix incorrect splitting in btrfs_drop_extent_map_range<br /> <br /> In production we were seeing a variety of WARN_ON()&amp;#39;s in the extent_map<br /> code, specifically in btrfs_drop_extent_map_range() when we have to call<br /> add_extent_mapping() for our second split.<br /> <br /> Consider the following extent map layout<br /> <br /> PINNED<br /> [0 16K) [32K, 48K)<br /> <br /> and then we call btrfs_drop_extent_map_range for [0, 36K), with<br /> skip_pinned == true. The initial loop will have<br /> <br /> start = 0<br /> end = 36K<br /> len = 36K<br /> <br /> we will find the [0, 16k) extent, but since we are pinned we will skip<br /> it, which has this code<br /> <br /> start = em_end;<br /> if (end != (u64)-1)<br /> len = start + len - em_end;<br /> <br /> em_end here is 16K, so now the values are<br /> <br /> start = 16K<br /> len = 16K + 36K - 16K = 36K<br /> <br /> len should instead be 20K. This is a problem when we find the next<br /> extent at [32K, 48K), we need to split this extent to leave [36K, 48k),<br /> however the code for the split looks like this<br /> <br /> split-&gt;start = start + len;<br /> split-&gt;len = em_end - (start + len);<br /> <br /> In this case we have<br /> <br /> em_end = 48K<br /> split-&gt;start = 16K + 36K // this should be 16K + 20K<br /> split-&gt;len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52K<br /> <br /> and now we have an invalid extent_map in the tree that potentially<br /> overlaps other entries in the extent map. Even in the non-overlapping<br /> case we will have split-&gt;start set improperly, which will cause problems<br /> with any block related calculations.<br /> <br /> We don&amp;#39;t actually need len in this loop, we can simply use end as our<br /> end point, and only adjust start up when we find a pinned extent we need<br /> to skip.<br /> <br /> Adjust the logic to do this, which keeps us from inserting an invalid<br /> extent map.<br /> <br /> We only skip_pinned in the relocation case, so this is relatively rare,<br /> except in the case where you are running relocation a lot, which can<br /> happen with auto relocation on.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: Add check for cstate<br /> <br /> As kzalloc may fail and return NULL pointer,<br /> it should be better to check cstate<br /> in order to avoid the NULL pointer dereference<br /> in __drm_atomic_helper_crtc_reset.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/514163/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: fix memleak for &amp;#39;conf-&gt;bio_split&amp;#39;<br /> <br /> In the error path of raid10_run(), &amp;#39;conf&amp;#39; need be freed, however,<br /> &amp;#39;conf-&gt;bio_split&amp;#39; is missed and memory will be leaked.<br /> <br /> Since there are 3 places to free &amp;#39;conf&amp;#39;, factor out a helper to fix the<br /> problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to drop all dirty pages during umount() if cp_error is set<br /> <br /> xfstest generic/361 reports a bug as below:<br /> <br /> f2fs_bug_on(sbi, sbi-&gt;fsync_node_num);<br /> <br /> kernel BUG at fs/f2fs/super.c:1627!<br /> RIP: 0010:f2fs_put_super+0x3a8/0x3b0<br /> Call Trace:<br /> generic_shutdown_super+0x8c/0x1b0<br /> kill_block_super+0x2b/0x60<br /> kill_f2fs_super+0x87/0x110<br /> deactivate_locked_super+0x39/0x80<br /> deactivate_super+0x46/0x50<br /> cleanup_mnt+0x109/0x170<br /> __cleanup_mnt+0x16/0x20<br /> task_work_run+0x65/0xa0<br /> exit_to_user_mode_prepare+0x175/0x190<br /> syscall_exit_to_user_mode+0x25/0x50<br /> do_syscall_64+0x4c/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> During umount(), if cp_error is set, f2fs_wait_on_all_pages() should<br /> not stop waiting all F2FS_WB_CP_DATA pages to be writebacked, otherwise,<br /> fsync_node_num can be non-zero after f2fs_wait_on_all_pages() causing<br /> this bug.<br /> <br /> In this case, to avoid deadloop in f2fs_wait_on_all_pages(), it needs<br /> to drop all dirty pages rather than redirtying them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Return error for inconsistent extended attributes<br /> <br /> ntfs_read_ea is called when we want to read extended attributes. There<br /> are some sanity checks for the validity of the EAs. However, it fails to<br /> return a proper error code for the inconsistent attributes, which might<br /> lead to unpredicted memory accesses after return.<br /> <br /> [ 138.916927] BUG: KASAN: use-after-free in ntfs_set_ea+0x453/0xbf0<br /> [ 138.923876] Write of size 4 at addr ffff88800205cfac by task poc/199<br /> [ 138.931132]<br /> [ 138.933016] CPU: 0 PID: 199 Comm: poc Not tainted 6.2.0-rc1+ #4<br /> [ 138.938070] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> [ 138.947327] Call Trace:<br /> [ 138.949557] <br /> [ 138.951539] dump_stack_lvl+0x4d/0x67<br /> [ 138.956834] print_report+0x16f/0x4a6<br /> [ 138.960798] ? ntfs_set_ea+0x453/0xbf0<br /> [ 138.964437] ? kasan_complete_mode_report_info+0x7d/0x200<br /> [ 138.969793] ? ntfs_set_ea+0x453/0xbf0<br /> [ 138.973523] kasan_report+0xb8/0x140<br /> [ 138.976740] ? ntfs_set_ea+0x453/0xbf0<br /> [ 138.980578] __asan_store4+0x76/0xa0<br /> [ 138.984669] ntfs_set_ea+0x453/0xbf0<br /> [ 138.988115] ? __pfx_ntfs_set_ea+0x10/0x10<br /> [ 138.993390] ? kernel_text_address+0xd3/0xe0<br /> [ 138.998270] ? __kernel_text_address+0x16/0x50<br /> [ 139.002121] ? unwind_get_return_address+0x3e/0x60<br /> [ 139.005659] ? __pfx_stack_trace_consume_entry+0x10/0x10<br /> [ 139.010177] ? arch_stack_walk+0xa2/0x100<br /> [ 139.013657] ? filter_irq_stacks+0x27/0x80<br /> [ 139.017018] ntfs_setxattr+0x405/0x440<br /> [ 139.022151] ? __pfx_ntfs_setxattr+0x10/0x10<br /> [ 139.026569] ? kvmalloc_node+0x2d/0x120<br /> [ 139.030329] ? kasan_save_stack+0x41/0x60<br /> [ 139.033883] ? kasan_save_stack+0x2a/0x60<br /> [ 139.037338] ? kasan_set_track+0x29/0x40<br /> [ 139.040163] ? kasan_save_alloc_info+0x1f/0x30<br /> [ 139.043588] ? __kasan_kmalloc+0x8b/0xa0<br /> [ 139.047255] ? __kmalloc_node+0x68/0x150<br /> [ 139.051264] ? kvmalloc_node+0x2d/0x120<br /> [ 139.055301] ? vmemdup_user+0x2b/0xa0<br /> [ 139.058584] __vfs_setxattr+0x121/0x170<br /> [ 139.062617] ? __pfx___vfs_setxattr+0x10/0x10<br /> [ 139.066282] __vfs_setxattr_noperm+0x97/0x300<br /> [ 139.070061] __vfs_setxattr_locked+0x145/0x170<br /> [ 139.073580] vfs_setxattr+0x137/0x2a0<br /> [ 139.076641] ? __pfx_vfs_setxattr+0x10/0x10<br /> [ 139.080223] ? __kasan_check_write+0x18/0x20<br /> [ 139.084234] do_setxattr+0xce/0x150<br /> [ 139.087768] setxattr+0x126/0x140<br /> [ 139.091250] ? __pfx_setxattr+0x10/0x10<br /> [ 139.094948] ? __virt_addr_valid+0xcb/0x140<br /> [ 139.097838] ? __call_rcu_common.constprop.0+0x1c7/0x330<br /> [ 139.102688] ? debug_smp_processor_id+0x1b/0x30<br /> [ 139.105985] ? kasan_quarantine_put+0x5b/0x190<br /> [ 139.109980] ? putname+0x84/0xa0<br /> [ 139.113886] ? __kasan_slab_free+0x11e/0x1b0<br /> [ 139.117961] ? putname+0x84/0xa0<br /> [ 139.121316] ? preempt_count_sub+0x1c/0xd0<br /> [ 139.124427] ? __mnt_want_write+0xae/0x100<br /> [ 139.127836] ? mnt_want_write+0x8f/0x150<br /> [ 139.130954] path_setxattr+0x164/0x180<br /> [ 139.133998] ? __pfx_path_setxattr+0x10/0x10<br /> [ 139.137853] ? __pfx_ksys_pwrite64+0x10/0x10<br /> [ 139.141299] ? debug_smp_processor_id+0x1b/0x30<br /> [ 139.145714] ? fpregs_assert_state_consistent+0x6b/0x80<br /> [ 139.150796] __x64_sys_setxattr+0x71/0x90<br /> [ 139.155407] do_syscall_64+0x3f/0x90<br /> [ 139.159035] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> [ 139.163843] RIP: 0033:0x7f108cae4469<br /> [ 139.166481] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088<br /> [ 139.183764] RSP: 002b:00007fff87588388 EFLAGS: 00000286 ORIG_RAX: 00000000000000bc<br /> [ 139.190657] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f108cae4469<br /> [ 139.196586] RDX: 00007fff875883b0 RSI: 00007fff875883d1 RDI: 00007fff875883b6<br /> [ 139.201716] RBP: 00007fff8758c530 R08: 0000000000000001 R09: 00007fff8758c618<br /> [ 139.207940] R10: 0000000000000006 R11: 0000000000000286 R12: 00000000004004c0<br /> [ 139.214007] R13: 00007fff8758c610 R14: 0000000000000000 R15<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: safexcel - Cleanup ring IRQ workqueues on load failure<br /> <br /> A failure loading the safexcel driver results in the following warning<br /> on boot, because the IRQ affinity has not been correctly cleaned up.<br /> Ensure we clean up the affinity and workqueues on a failure to load the<br /> driver.<br /> <br /> crypto-safexcel: probe of f2800000.crypto failed with error -2<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 232 at kernel/irq/manage.c:1913 free_irq+0x300/0x340<br /> Modules linked in: hwmon mdio_i2c crypto_safexcel(+) md5 sha256_generic libsha256 authenc libdes omap_rng rng_core nft_masq nft_nat nft_chain_nat nf_nat nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink fuse autofs4<br /> CPU: 1 PID: 232 Comm: systemd-udevd Tainted: G W 6.1.6-00002-g9d4898824677 #3<br /> Hardware name: MikroTik RB5009 (DT)<br /> pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : free_irq+0x300/0x340<br /> lr : free_irq+0x2e0/0x340<br /> sp : ffff800008fa3890<br /> x29: ffff800008fa3890 x28: 0000000000000000 x27: 0000000000000000<br /> x26: ffff8000008e6dc0 x25: ffff000009034cac x24: ffff000009034d50<br /> x23: 0000000000000000 x22: 000000000000004a x21: ffff0000093e0d80<br /> x20: ffff000009034c00 x19: ffff00000615fc00 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 000075f5c1584c5e<br /> x14: 0000000000000017 x13: 0000000000000000 x12: 0000000000000040<br /> x11: ffff000000579b60 x10: ffff000000579b62 x9 : ffff800008bbe370<br /> x8 : ffff000000579dd0 x7 : 0000000000000000 x6 : ffff000000579e18<br /> x5 : ffff000000579da8 x4 : ffff800008ca0000 x3 : ffff800008ca0188<br /> x2 : 0000000013033204 x1 : ffff000009034c00 x0 : ffff8000087eadf0<br /> Call trace:<br /> free_irq+0x300/0x340<br /> devm_irq_release+0x14/0x20<br /> devres_release_all+0xa0/0x100<br /> device_unbind_cleanup+0x14/0x60<br /> really_probe+0x198/0x2d4<br /> __driver_probe_device+0x74/0xdc<br /> driver_probe_device+0x3c/0x110<br /> __driver_attach+0x8c/0x190<br /> bus_for_each_dev+0x6c/0xc0<br /> driver_attach+0x20/0x30<br /> bus_add_driver+0x148/0x1fc<br /> driver_register+0x74/0x120<br /> __platform_driver_register+0x24/0x30<br /> safexcel_init+0x48/0x1000 [crypto_safexcel]<br /> do_one_initcall+0x4c/0x1b0<br /> do_init_module+0x44/0x1cc<br /> load_module+0x1724/0x1be4<br /> __do_sys_finit_module+0xbc/0x110<br /> __arm64_sys_finit_module+0x1c/0x24<br /> invoke_syscall+0x44/0x110<br /> el0_svc_common.constprop.0+0xc0/0xe0<br /> do_el0_svc+0x20/0x80<br /> el0_svc+0x14/0x4c<br /> el0t_64_sync_handler+0xb0/0xb4<br /> el0t_64_sync+0x148/0x14c<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/jfs: prevent double-free in dbUnmount() after failed jfs_remount()<br /> <br /> Syzkaller reported the following issue:<br /> ==================================================================<br /> BUG: KASAN: double-free in slab_free mm/slub.c:3787 [inline]<br /> BUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3800<br /> Free of addr ffff888086408000 by task syz-executor.4/12750<br /> [...]<br /> Call Trace:<br /> <br /> [...]<br /> kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:482<br /> ____kasan_slab_free+0xfb/0x120<br /> kasan_slab_free include/linux/kasan.h:177 [inline]<br /> slab_free_hook mm/slub.c:1781 [inline]<br /> slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1807<br /> slab_free mm/slub.c:3787 [inline]<br /> __kmem_cache_free+0x71/0x110 mm/slub.c:3800<br /> dbUnmount+0xf4/0x110 fs/jfs/jfs_dmap.c:264<br /> jfs_umount+0x248/0x3b0 fs/jfs/jfs_umount.c:87<br /> jfs_put_super+0x86/0x190 fs/jfs/super.c:194<br /> generic_shutdown_super+0x130/0x310 fs/super.c:492<br /> kill_block_super+0x79/0xd0 fs/super.c:1386<br /> deactivate_locked_super+0xa7/0xf0 fs/super.c:332<br /> cleanup_mnt+0x494/0x520 fs/namespace.c:1291<br /> task_work_run+0x243/0x300 kernel/task_work.c:179<br /> resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]<br /> exit_to_user_mode_loop+0x124/0x150 kernel/entry/common.c:171<br /> exit_to_user_mode_prepare+0xb2/0x140 kernel/entry/common.c:203<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]<br /> syscall_exit_to_user_mode+0x26/0x60 kernel/entry/common.c:296<br /> do_syscall_64+0x49/0xb0 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [...]<br /> <br /> <br /> Allocated by task 13352:<br /> kasan_save_stack mm/kasan/common.c:45 [inline]<br /> kasan_set_track+0x3d/0x60 mm/kasan/common.c:52<br /> ____kasan_kmalloc mm/kasan/common.c:371 [inline]<br /> __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380<br /> kmalloc include/linux/slab.h:580 [inline]<br /> dbMount+0x54/0x980 fs/jfs/jfs_dmap.c:164<br /> jfs_mount+0x1dd/0x830 fs/jfs/jfs_mount.c:121<br /> jfs_fill_super+0x590/0xc50 fs/jfs/super.c:556<br /> mount_bdev+0x26c/0x3a0 fs/super.c:1359<br /> legacy_get_tree+0xea/0x180 fs/fs_context.c:610<br /> vfs_get_tree+0x88/0x270 fs/super.c:1489<br /> do_new_mount+0x289/0xad0 fs/namespace.c:3145<br /> do_mount fs/namespace.c:3488 [inline]<br /> __do_sys_mount fs/namespace.c:3697 [inline]<br /> __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Freed by task 13352:<br /> kasan_save_stack mm/kasan/common.c:45 [inline]<br /> kasan_set_track+0x3d/0x60 mm/kasan/common.c:52<br /> kasan_save_free_info+0x27/0x40 mm/kasan/generic.c:518<br /> ____kasan_slab_free+0xd6/0x120 mm/kasan/common.c:236<br /> kasan_slab_free include/linux/kasan.h:177 [inline]<br /> slab_free_hook mm/slub.c:1781 [inline]<br /> slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1807<br /> slab_free mm/slub.c:3787 [inline]<br /> __kmem_cache_free+0x71/0x110 mm/slub.c:3800<br /> dbUnmount+0xf4/0x110 fs/jfs/jfs_dmap.c:264<br /> jfs_mount_rw+0x545/0x740 fs/jfs/jfs_mount.c:247<br /> jfs_remount+0x3db/0x710 fs/jfs/super.c:454<br /> reconfigure_super+0x3bc/0x7b0 fs/super.c:935<br /> vfs_fsconfig_locked fs/fsopen.c:254 [inline]<br /> __do_sys_fsconfig fs/fsopen.c:439 [inline]<br /> __se_sys_fsconfig+0xad5/0x1060 fs/fsopen.c:314<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [...]<br /> <br /> JFS_SBI(ipbmap-&gt;i_sb)-&gt;bmap wasn&amp;#39;t set to NULL after kfree() in<br /> dbUnmount().<br /> <br /> Syzkaller uses faultinject to reproduce this KASAN double-free<br /> warning. The issue is triggered if either diMount() or dbMount() fail<br /> in jfs_remount(), since diUnmount() or dbUnmount() already happened in<br /> such a case - they will do double-free on next execution: jfs_umount<br /> or jfs_remount.<br /> <br /> Tested on both upstream and jfs-next by syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: drop peer group ids under namespace lock<br /> <br /> When cleaning up peer group ids in the failure path we need to make sure<br /> to hold on to the namespace lock. Otherwise another thread might just<br /> turn the mount from a shared into a non-shared mount concurrently.