Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: check if leafidx greater than num leaves per dmap tree<br /> <br /> syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater<br /> than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.<br /> <br /> Shaggy:<br /> Modified sanity check to apply to control pages as well as leaf pages.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: Fix uaf in dbFreeBits<br /> <br /> [syzbot reported]<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline]<br /> BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752<br /> Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216<br /> <br /> CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:93 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> __mutex_lock_common kernel/locking/mutex.c:587 [inline]<br /> __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752<br /> dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390<br /> dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline]<br /> dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409<br /> dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650<br /> jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100<br /> jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> <br /> Freed by task 5218:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579<br /> poison_slab_object+0xe0/0x150 mm/kasan/common.c:240<br /> __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256<br /> kasan_slab_free include/linux/kasan.h:184 [inline]<br /> slab_free_hook mm/slub.c:2252 [inline]<br /> slab_free mm/slub.c:4473 [inline]<br /> kfree+0x149/0x360 mm/slub.c:4594<br /> dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278<br /> jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247<br /> jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454<br /> reconfigure_super+0x445/0x880 fs/super.c:1083<br /> vfs_cmd_reconfigure fs/fsopen.c:263 [inline]<br /> vfs_fsconfig_locked fs/fsopen.c:292 [inline]<br /> __do_sys_fsconfig fs/fsopen.c:473 [inline]<br /> __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345<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 /> [Analysis]<br /> There are two paths (dbUnmount and jfs_ioc_trim) that generate race<br /> condition when accessing bmap, which leads to the occurrence of uaf.<br /> <br /> Use the lock s_umount to synchronize them, in order to avoid uaf caused<br /> by race condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm, slub: avoid zeroing kmalloc redzone<br /> <br /> Since commit 946fa0dbf2d8 ("mm/slub: extend redzone check to extra<br /> allocated kmalloc space than requested"), setting orig_size treats<br /> the wasted space (object_size - orig_size) as a redzone. However with<br /> init_on_free=1 we clear the full object-&gt;size, including the redzone.<br /> <br /> Additionally we clear the object metadata, including the stored orig_size,<br /> making it zero, which makes check_object() treat the whole object as a<br /> redzone.<br /> <br /> These issues lead to the following BUG report with "slub_debug=FUZ<br /> init_on_free=1":<br /> <br /> [ 0.000000] =============================================================================<br /> [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten<br /> [ 0.000000] -----------------------------------------------------------------------------<br /> [ 0.000000]<br /> [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc<br /> [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc<br /> [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff)<br /> [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8<br /> [ 0.000000]<br /> [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........<br /> [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........<br /> [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........<br /> [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............<br /> [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144<br /> [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT)<br /> [ 0.000000] Call trace:<br /> [ 0.000000] dump_backtrace+0x90/0xe8<br /> [ 0.000000] show_stack+0x18/0x24<br /> [ 0.000000] dump_stack_lvl+0x74/0x8c<br /> [ 0.000000] dump_stack+0x18/0x24<br /> [ 0.000000] print_trailer+0x150/0x218<br /> [ 0.000000] check_object+0xe4/0x454<br /> [ 0.000000] free_to_partial_list+0x2f8/0x5ec<br /> <br /> To address the issue, use orig_size to clear the used area. And restore<br /> the value of orig_size after clear the remaining area.<br /> <br /> When CONFIG_SLUB_DEBUG not defined, (get_orig_size()&amp;#39; directly returns<br /> s-&gt;object_size. So when using memset to init the area, the size can simply<br /> be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not<br /> enabled. And orig_size can never be bigger than object_size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to don&amp;#39;t panic system for no free segment fault injection<br /> <br /> f2fs: fix to don&amp;#39;t panic system for no free segment fault injection<br /> <br /> syzbot reports a f2fs bug as below:<br /> <br /> F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167<br /> F2FS-fs (loop0): Stopped filesystem due to reason: 7<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/segment.c:2748!<br /> CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0<br /> RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline]<br /> RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836<br /> Call Trace:<br /> __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167<br /> f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline]<br /> f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195<br /> f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799<br /> f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903<br /> vfs_fallocate+0x553/0x6c0 fs/open.c:334<br /> do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886<br /> __do_sys_ioctl fs/ioctl.c:905 [inline]<br /> __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893<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 /> RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline]<br /> RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836<br /> <br /> The root cause is when we inject no free segment fault into f2fs,<br /> we should not panic system, fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix a sdiv overflow issue<br /> <br /> Zac Ecob reported a problem where a bpf program may cause kernel crash due<br /> to the following error:<br /> Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI<br /> <br /> The failure is due to the below signed divide:<br /> LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808.<br /> LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808,<br /> but it is impossible since for 64-bit system, the maximum positive<br /> number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will<br /> cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is<br /> LLONG_MIN.<br /> <br /> Further investigation found all the following sdiv/smod cases may trigger<br /> an exception when bpf program is running on x86_64 platform:<br /> - LLONG_MIN/-1 for 64bit operation<br /> - INT_MIN/-1 for 32bit operation<br /> - LLONG_MIN%-1 for 64bit operation<br /> - INT_MIN%-1 for 32bit operation<br /> where -1 can be an immediate or in a register.<br /> <br /> On arm64, there are no exceptions:<br /> - LLONG_MIN/-1 = LLONG_MIN<br /> - INT_MIN/-1 = INT_MIN<br /> - LLONG_MIN%-1 = 0<br /> - INT_MIN%-1 = 0<br /> where -1 can be an immediate or in a register.<br /> <br /> Insn patching is needed to handle the above cases and the patched codes<br /> produced results aligned with above arm64 result. The below are pseudo<br /> codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0<br /> and the divisor is stored in a register.<br /> <br /> sdiv:<br /> tmp = rX<br /> tmp += 1 /* [-1, 0] -&gt; [0, 1]<br /> if tmp &gt;(unsigned) 1 goto L2<br /> if tmp == 0 goto L1<br /> rY = 0<br /> L1:<br /> rY = -rY;<br /> goto L3<br /> L2:<br /> rY /= rX<br /> L3:<br /> <br /> smod:<br /> tmp = rX<br /> tmp += 1 /* [-1, 0] -&gt; [0, 1]<br /> if tmp &gt;(unsigned) 1 goto L1<br /> if tmp == 1 (is64 ? goto L2 : goto L3)<br /> rY = 0;<br /> goto L2<br /> L1:<br /> rY %= rX<br /> L2:<br /> goto L4 // only when !is64<br /> L3:<br /> wY = wY // only when !is64<br /> L4:<br /> <br /> [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check stream_status before it is used<br /> <br /> [WHAT &amp; HOW]<br /> dc_state_get_stream_status can return null, and therefore null must be<br /> checked before stream_status is used.<br /> <br /> This fixes 1 NULL_RETURNS issue reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths<br /> <br /> When the HBA is undergoing a reset or is handling an errata event, NULL ptr<br /> dereference crashes may occur in routines such as<br /> lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or<br /> lpfc_abort_handler().<br /> <br /> Add NULL ptr checks before dereferencing hdwq pointers that may have been<br /> freed due to operations colliding with a reset or errata event handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug<br /> <br /> Attaching SST PCI device to VM causes "BUG: KASAN: slab-out-of-bounds".<br /> kasan report:<br /> [ 19.411889] ==================================================================<br /> [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]<br /> [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113<br /> [ 19.417368]<br /> [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10<br /> [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022<br /> [ 19.422687] Call Trace:<br /> [ 19.424091] <br /> [ 19.425448] dump_stack_lvl+0x5d/0x80<br /> [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]<br /> [ 19.428694] print_report+0x19d/0x52e<br /> [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]<br /> [ 19.433539] kasan_report+0xf0/0x170<br /> [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]<br /> [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]<br /> [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10<br /> [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common]<br /> [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common]<br /> [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360<br /> [ 19.444797] cpuhp_invoke_callback+0x221/0xec0<br /> [ 19.446337] cpuhp_thread_fun+0x21b/0x610<br /> [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10<br /> [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0<br /> [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10<br /> [ 19.452405] kthread+0x29c/0x350<br /> [ 19.453817] ? __pfx_kthread+0x10/0x10<br /> [ 19.455253] ret_from_fork+0x31/0x70<br /> [ 19.456685] ? __pfx_kthread+0x10/0x10<br /> [ 19.458114] ret_from_fork_asm+0x1a/0x30<br /> [ 19.459573] <br /> [ 19.460853]<br /> [ 19.462055] Allocated by task 1198:<br /> [ 19.463410] kasan_save_stack+0x30/0x50<br /> [ 19.464788] kasan_save_track+0x14/0x30<br /> [ 19.466139] __kasan_kmalloc+0xaa/0xb0<br /> [ 19.467465] __kmalloc+0x1cd/0x470<br /> [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common]<br /> [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr]<br /> [ 19.471670] do_one_initcall+0xa4/0x380<br /> [ 19.472903] do_init_module+0x238/0x760<br /> [ 19.474105] load_module+0x5239/0x6f00<br /> [ 19.475285] init_module_from_file+0xd1/0x130<br /> [ 19.476506] idempotent_init_module+0x23b/0x650<br /> [ 19.477725] __x64_sys_finit_module+0xbe/0x130<br /> [ 19.476506] idempotent_init_module+0x23b/0x650<br /> [ 19.477725] __x64_sys_finit_module+0xbe/0x130<br /> [ 19.478920] do_syscall_64+0x82/0x160<br /> [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 19.481292]<br /> [ 19.482205] The buggy address belongs to the object at ffff888829e65000<br /> which belongs to the cache kmalloc-512 of size 512<br /> [ 19.484818] The buggy address is located 0 bytes to the right of<br /> allocated 512-byte region [ffff888829e65000, ffff888829e65200)<br /> [ 19.487447]<br /> [ 19.488328] The buggy address belongs to the physical page:<br /> [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60<br /> [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff)<br /> [ 19.493914] page_type: 0xffffffff()<br /> [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001<br /> [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000<br /> [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001<br /> [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000<br /> [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff<br /> [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000<br /> [ 19.503784] page dumped because: k<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation<br /> <br /> This commit addresses a potential index out of bounds issue in the<br /> `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30<br /> color management module. The issue could occur when the index &amp;#39;i&amp;#39;<br /> exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).<br /> <br /> The fix adds a check to ensure &amp;#39;i&amp;#39; is within bounds before accessing the<br /> transfer function points. If &amp;#39;i&amp;#39; is out of bounds, the function returns<br /> false to indicate an error.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &amp;#39;output_tf-&gt;tf_pts.red&amp;#39; 1025 tf_pts.green&amp;#39; 1025 tf_pts.blue&amp;#39; 1025

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid use-after-free in ext4_ext_show_leaf()<br /> <br /> In ext4_find_extent(), path may be freed by error or be reallocated, so<br /> using a previously saved *ppath may have been freed and thus may trigger<br /> use-after-free, as follows:<br /> <br /> ext4_split_extent<br /> path = *ppath;<br /> ext4_split_extent_at(ppath)<br /> path = ext4_find_extent(ppath)<br /> ext4_split_extent_at(ppath)<br /> // ext4_find_extent fails to free path<br /> // but zeroout succeeds<br /> ext4_ext_show_leaf(inode, path)<br /> eh = path[depth].p_hdr<br /> // path use-after-free !!!<br /> <br /> Similar to ext4_split_extent_at(), we use *ppath directly as an input to<br /> ext4_ext_show_leaf(). Fix a spelling error by the way.<br /> <br /> Same problem in ext4_ext_handle_unwritten_extents(). Since &amp;#39;path&amp;#39; is only<br /> used in ext4_ext_show_leaf(), remove &amp;#39;path&amp;#39; and use *ppath directly.<br /> <br /> This issue is triggered only when EXT_DEBUG is defined and therefore does<br /> not affect functionality.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: ensure the fw_info is not null before using it<br /> <br /> This resolves the dereference null return value warning<br /> reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Initialize get_bytes_per_element&amp;#39;s default to 1<br /> <br /> Variables, used as denominators and maybe not assigned to other values,<br /> should not be 0. bytes_per_element_y &amp; bytes_per_element_c are<br /> initialized by get_bytes_per_element() which should never return 0.<br /> <br /> This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.