Vulnerabilities

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 /> ext4: aovid use-after-free in ext4_ext_insert_extent()<br /> <br /> As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is<br /> reallocated in ext4_ext_create_new_leaf(), we&amp;#39;ll use the stale path and<br /> cause UAF. Below is a sample trace with dummy values:<br /> <br /> ext4_ext_insert_extent<br /> path = *ppath = 2000<br /> ext4_ext_create_new_leaf(ppath)<br /> ext4_find_extent(ppath)<br /> path = *ppath = 2000<br /> if (depth &gt; path[0].p_maxdepth)<br /> kfree(path = 2000);<br /> *ppath = path = NULL;<br /> path = kcalloc() = 3000<br /> *ppath = 3000;<br /> return path;<br /> /* here path is still 2000, UAF! */<br /> eh = path[depth].p_hdr<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330<br /> Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179<br /> CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866<br /> Call Trace:<br /> <br /> ext4_ext_insert_extent+0x26d4/0x3330<br /> ext4_ext_map_blocks+0xe22/0x2d40<br /> ext4_map_blocks+0x71e/0x1700<br /> ext4_do_writepages+0x1290/0x2800<br /> [...]<br /> <br /> Allocated by task 179:<br /> ext4_find_extent+0x81c/0x1f70<br /> ext4_ext_map_blocks+0x146/0x2d40<br /> ext4_map_blocks+0x71e/0x1700<br /> ext4_do_writepages+0x1290/0x2800<br /> ext4_writepages+0x26d/0x4e0<br /> do_writepages+0x175/0x700<br /> [...]<br /> <br /> Freed by task 179:<br /> kfree+0xcb/0x240<br /> ext4_find_extent+0x7c0/0x1f70<br /> ext4_ext_insert_extent+0xa26/0x3330<br /> ext4_ext_map_blocks+0xe22/0x2d40<br /> ext4_map_blocks+0x71e/0x1700<br /> ext4_do_writepages+0x1290/0x2800<br /> ext4_writepages+0x26d/0x4e0<br /> do_writepages+0x175/0x700<br /> [...]<br /> ==================================================================<br /> <br /> So use *ppath to update the path to avoid the above problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix slab-use-after-free in ext4_split_extent_at()<br /> <br /> We hit the following use-after-free:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0<br /> Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40<br /> CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724<br /> Call Trace:<br /> <br /> kasan_report+0x93/0xc0<br /> ext4_split_extent_at+0xba8/0xcc0<br /> ext4_split_extent.isra.0+0x18f/0x500<br /> ext4_split_convert_extents+0x275/0x750<br /> ext4_ext_handle_unwritten_extents+0x73e/0x1580<br /> ext4_ext_map_blocks+0xe20/0x2dc0<br /> ext4_map_blocks+0x724/0x1700<br /> ext4_do_writepages+0x12d6/0x2a70<br /> [...]<br /> <br /> Allocated by task 40:<br /> __kmalloc_noprof+0x1ac/0x480<br /> ext4_find_extent+0xf3b/0x1e70<br /> ext4_ext_map_blocks+0x188/0x2dc0<br /> ext4_map_blocks+0x724/0x1700<br /> ext4_do_writepages+0x12d6/0x2a70<br /> [...]<br /> <br /> Freed by task 40:<br /> kfree+0xf1/0x2b0<br /> ext4_find_extent+0xa71/0x1e70<br /> ext4_ext_insert_extent+0xa22/0x3260<br /> ext4_split_extent_at+0x3ef/0xcc0<br /> ext4_split_extent.isra.0+0x18f/0x500<br /> ext4_split_convert_extents+0x275/0x750<br /> ext4_ext_handle_unwritten_extents+0x73e/0x1580<br /> ext4_ext_map_blocks+0xe20/0x2dc0<br /> ext4_map_blocks+0x724/0x1700<br /> ext4_do_writepages+0x12d6/0x2a70<br /> [...]<br /> ==================================================================<br /> <br /> The flow of issue triggering is as follows:<br /> <br /> ext4_split_extent_at<br /> path = *ppath<br /> ext4_ext_insert_extent(ppath)<br /> ext4_ext_create_new_leaf(ppath)<br /> ext4_find_extent(orig_path)<br /> path = *orig_path<br /> read_extent_tree_block<br /> // return -ENOMEM or -EIO<br /> ext4_free_ext_path(path)<br /> kfree(path)<br /> *orig_path = NULL<br /> a. If err is -ENOMEM:<br /> ext4_ext_dirty(path + path-&gt;p_depth)<br /> // path use-after-free !!!<br /> b. If err is -EIO and we have EXT_DEBUG defined:<br /> ext4_ext_show_leaf(path)<br /> eh = path[depth].p_hdr<br /> // path also use-after-free !!!<br /> <br /> So when trying to zeroout or fix the extent length, call ext4_find_extent()<br /> to update the path.<br /> <br /> In addition we use *ppath directly as an ext4_ext_show_leaf() input to<br /> avoid possible use-after-free when EXT_DEBUG is defined, and to avoid<br /> unnecessary path updates.

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 /> 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix index out of bounds in degamma hardware format translation<br /> <br /> Fixes index out of bounds issue in<br /> `cm_helper_translate_curve_to_degamma_hw_format` function. The issue<br /> could occur when the index &amp;#39;i&amp;#39; exceeds the number of transfer function<br /> 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/dcn10/dcn10_cm_common.c:594 cm_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