Vulnerabilities

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

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: fix off by one issue in alloc_flex_gd()<br /> <br /> Wesley reported an issue:<br /> <br /> ==================================================================<br /> EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/ext4/resize.c:324!<br /> CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27<br /> RIP: 0010:ext4_resize_fs+0x1212/0x12d0<br /> Call Trace:<br /> __ext4_ioctl+0x4e0/0x1800<br /> ext4_ioctl+0x12/0x20<br /> __x64_sys_ioctl+0x99/0xd0<br /> x64_sys_call+0x1206/0x20d0<br /> do_syscall_64+0x72/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ==================================================================<br /> <br /> While reviewing the patch, Honza found that when adjusting resize_bg in<br /> alloc_flex_gd(), it was possible for flex_gd-&gt;resize_bg to be bigger than<br /> flexbg_size.<br /> <br /> The reproduction of the problem requires the following:<br /> <br /> o_group = flexbg_size * 2 * n;<br /> o_size = (o_group + 1) * group_size;<br /> n_group: [o_group + flexbg_size, o_group + flexbg_size * 2)<br /> o_size = (n_group + 1) * group_size;<br /> <br /> Take n=0,flexbg_size=16 as an example:<br /> <br /> last:15<br /> |o---------------|--------------n-|<br /> o_group:0 resize to n_group:30<br /> <br /> The corresponding reproducer is:<br /> <br /> img=test.img<br /> rm -f $img<br /> truncate -s 600M $img<br /> mkfs.ext4 -F $img -b 1024 -G 16 8M<br /> dev=`losetup -f --show $img`<br /> mkdir -p /tmp/test<br /> mount $dev /tmp/test<br /> resize2fs $dev 248M<br /> <br /> Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE()<br /> to prevent the issue from happening again.<br /> <br /> [ Note: another reproucer which this commit fixes is:<br /> <br /> img=test.img<br /> rm -f $img<br /> truncate -s 25MiB $img<br /> mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img<br /> truncate -s 3GiB $img<br /> dev=`losetup -f --show $img`<br /> mkdir -p /tmp/test<br /> mount $dev /tmp/test<br /> resize2fs $dev 3G<br /> umount $dev<br /> losetup -d $dev<br /> <br /> -- TYT ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: omapdrm: Add missing check for alloc_ordered_workqueue<br /> <br /> As it may return NULL pointer and cause NULL pointer dereference. Add check<br /> for the return value of alloc_ordered_workqueue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: update orig_path in ext4_find_extent()<br /> <br /> In ext4_find_extent(), if the path is not big enough, we free it and set<br /> *orig_path to NULL. But after reallocating and successfully initializing<br /> the path, we don&amp;#39;t update *orig_path, in which case the caller gets a<br /> valid path but a NULL ppath, and this may cause a NULL pointer dereference<br /> or a path memory leak. For example:<br /> <br /> ext4_split_extent<br /> path = *ppath = 2000<br /> ext4_find_extent<br /> if (depth &gt; path[0].p_maxdepth)<br /> kfree(path = 2000);<br /> *orig_path = path = NULL;<br /> path = kcalloc() = 3000<br /> ext4_split_extent_at(*ppath = NULL)<br /> path = *ppath;<br /> ex = path[depth].p_ext;<br /> // NULL pointer dereference!<br /> <br /> ==================================================================<br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847<br /> RIP: 0010:ext4_split_extent_at+0x6d/0x560<br /> Call Trace:<br /> <br /> ext4_split_extent.isra.0+0xcb/0x1b0<br /> ext4_ext_convert_to_initialized+0x168/0x6c0<br /> ext4_ext_handle_unwritten_extents+0x325/0x4d0<br /> ext4_ext_map_blocks+0x520/0xdb0<br /> ext4_map_blocks+0x2b0/0x690<br /> ext4_iomap_begin+0x20e/0x2c0<br /> [...]<br /> ==================================================================<br /> <br /> Therefore, *orig_path is updated when the extent lookup succeeds, so that<br /> the caller can safely use path or *ppath.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix double brelse() the buffer of the extents path<br /> <br /> In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been<br /> released, otherwise it may be released twice. An example of what triggers<br /> this is as follows:<br /> <br /> split2 map split1<br /> |--------|-------|--------|<br /> <br /> ext4_ext_map_blocks<br /> ext4_ext_handle_unwritten_extents<br /> ext4_split_convert_extents<br /> // path-&gt;p_depth == 0<br /> ext4_split_extent<br /> // 1. do split1<br /> ext4_split_extent_at<br /> |ext4_ext_insert_extent<br /> | ext4_ext_create_new_leaf<br /> | ext4_ext_grow_indepth<br /> | le16_add_cpu(&amp;neh-&gt;eh_depth, 1)<br /> | ext4_find_extent<br /> | // return -ENOMEM<br /> |// get error and try zeroout<br /> |path = ext4_find_extent<br /> | path-&gt;p_depth = 1<br /> |ext4_ext_try_to_merge<br /> | ext4_ext_try_to_merge_up<br /> | path-&gt;p_depth = 0<br /> | brelse(path[1].p_bh) ---&gt; not set to NULL here<br /> |// zeroout success<br /> // 2. update path<br /> ext4_find_extent<br /> // 3. do split2<br /> ext4_split_extent_at<br /> ext4_ext_insert_extent<br /> ext4_ext_create_new_leaf<br /> ext4_ext_grow_indepth<br /> le16_add_cpu(&amp;neh-&gt;eh_depth, 1)<br /> ext4_find_extent<br /> path[0].p_bh = NULL;<br /> path-&gt;p_depth = 1<br /> read_extent_tree_block ---&gt; return err<br /> // path[1].p_bh is still the old value<br /> ext4_free_ext_path<br /> ext4_ext_drop_refs<br /> // path-&gt;p_depth == 1<br /> brelse(path[1].p_bh) ---&gt; brelse a buffer twice<br /> <br /> Finally got the following WARRNING when removing the buffer from lru:<br /> <br /> ============================================<br /> VFS: brelse: Trying to free free buffer<br /> WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90<br /> CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716<br /> RIP: 0010:__brelse+0x58/0x90<br /> Call Trace:<br /> <br /> __find_get_block+0x6e7/0x810<br /> bdev_getblk+0x2b/0x480<br /> __ext4_get_inode_loc+0x48a/0x1240<br /> ext4_get_inode_loc+0xb2/0x150<br /> ext4_reserve_inode_write+0xb7/0x230<br /> __ext4_mark_inode_dirty+0x144/0x6a0<br /> ext4_ext_insert_extent+0x9c8/0x3230<br /> ext4_ext_map_blocks+0xf45/0x2dc0<br /> ext4_map_blocks+0x724/0x1700<br /> ext4_do_writepages+0x12d6/0x2a70<br /> [...]<br /> ============================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: fix UAF around queue destruction<br /> <br /> We currently do stuff like queuing the final destruction step on a<br /> random system wq, which will outlive the driver instance. With bad<br /> timing we can teardown the driver with one or more work workqueue still<br /> being alive leading to various UAF splats. Add a fini step to ensure<br /> user queues are properly torn down. At this point GuC should already be<br /> nuked so queue itself should no longer be referenced from hw pov.<br /> <br /> v2 (Matt B)<br /> - Looks much safer to use a waitqueue and then just wait for the<br /> xa_array to become empty before triggering the drain.<br /> <br /> (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: map the EBADMSG to nfserr_io to avoid warning<br /> <br /> Ext4 will throw -EBADMSG through ext4_readdir when a checksum error<br /> occurs, resulting in the following WARNING.<br /> <br /> Fix it by mapping EBADMSG to nfserr_io.<br /> <br /> nfsd_buffered_readdir<br /> iterate_dir // -EBADMSG -74<br /> ext4_readdir // .iterate_shared<br /> ext4_dx_readdir<br /> ext4_htree_fill_tree<br /> htree_dirblock_to_tree<br /> ext4_read_dirblock<br /> __ext4_read_dirblock<br /> ext4_dirblock_csum_verify<br /> warn_no_space_for_csum<br /> __warn_no_space_for_csum<br /> return ERR_PTR(-EFSBADCRC) // -EBADMSG -74<br /> nfserrno // WARNING<br /> <br /> [ 161.115610] ------------[ cut here ]------------<br /> [ 161.116465] nfsd: non-standard errno: -74<br /> [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0<br /> [ 161.118596] Modules linked in:<br /> [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138<br /> [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe<br /> mu.org 04/01/2014<br /> [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0<br /> [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6<br /> 05 ce 2b 61 03 01 e8 99 20 d8 00 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33<br /> [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286<br /> [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a<br /> [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827<br /> [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021<br /> [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8<br /> [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000<br /> [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0<br /> [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 161.141519] PKRU: 55555554<br /> [ 161.142076] Call Trace:<br /> [ 161.142575] ? __warn+0x9b/0x140<br /> [ 161.143229] ? nfserrno+0x9d/0xd0<br /> [ 161.143872] ? report_bug+0x125/0x150<br /> [ 161.144595] ? handle_bug+0x41/0x90<br /> [ 161.145284] ? exc_invalid_op+0x14/0x70<br /> [ 161.146009] ? asm_exc_invalid_op+0x12/0x20<br /> [ 161.146816] ? nfserrno+0x9d/0xd0<br /> [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0<br /> [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380<br /> [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0<br /> [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170<br /> [ 161.151004] ? generic_file_llseek_size+0x48/0x160<br /> [ 161.151895] nfsd_readdir+0x132/0x190<br /> [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380<br /> [ 161.153516] ? nfsd_unlink+0x380/0x380<br /> [ 161.154256] ? override_creds+0x45/0x60<br /> [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0<br /> [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210<br /> [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0<br /> [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0<br /> [ 161.158494] ? lock_downgrade+0x90/0x90<br /> [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10<br /> [ 161.160092] nfsd4_encode_operation+0x15a/0x440<br /> [ 161.160959] nfsd4_proc_compound+0x718/0xe90<br /> [ 161.161818] nfsd_dispatch+0x18e/0x2c0<br /> [ 161.162586] svc_process_common+0x786/0xc50<br /> [ 161.163403] ? nfsd_svc+0x380/0x380<br /> [ 161.164137] ? svc_printk+0x160/0x160<br /> [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380<br /> [ 161.165808] ? nfsd_svc+0x380/0x380<br /> [ 161.166523] ? rcu_is_watching+0x23/0x40<br /> [ 161.167309] svc_process+0x1a5/0x200<br /> [ 161.168019] nfsd+0x1f5/0x380<br /> [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260<br /> [ 161.169554] kthread+0x1c4/0x210<br /> [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80<br /> [ 161.171246] ret_from_fork+0x1f/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate<br /> <br /> When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger<br /> NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if<br /> bh is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> resource: fix region_intersects() vs add_memory_driver_managed()<br /> <br /> On a system with CXL memory, the resource tree (/proc/iomem) related to<br /> CXL memory may look like something as follows.<br /> <br /> 490000000-50fffffff : CXL Window 0<br /> 490000000-50fffffff : region0<br /> 490000000-50fffffff : dax0.0<br /> 490000000-50fffffff : System RAM (kmem)<br /> <br /> Because drivers/dax/kmem.c calls add_memory_driver_managed() during<br /> onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL<br /> Window X". This confuses region_intersects(), which expects all "System<br /> RAM" resources to be at the top level of iomem_resource. This can lead to<br /> bugs.<br /> <br /> For example, when the following command line is executed to write some<br /> memory in CXL memory range via /dev/mem,<br /> <br /> $ dd if=data of=/dev/mem bs=$((1 10)) count=1<br /> dd: error writing &amp;#39;/dev/mem&amp;#39;: Bad address<br /> 1+0 records in<br /> 0+0 records out<br /> 0 bytes copied, 0.0283507 s, 0.0 kB/s<br /> <br /> the command fails as expected. However, the error code is wrong. It<br /> should be "Operation not permitted" instead of "Bad address". More<br /> seriously, the /dev/mem permission checking in devmem_is_allowed() passes<br /> incorrectly. Although the accessing is prevented later because ioremap()<br /> isn&amp;#39;t allowed to map system RAM, it is a potential security issue. During<br /> command executing, the following warning is reported in the kernel log for<br /> calling ioremap() on system RAM.<br /> <br /> ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff<br /> WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d<br /> Call Trace:<br /> memremap+0xcb/0x184<br /> xlate_dev_mem_ptr+0x25/0x2f<br /> write_mem+0x94/0xfb<br /> vfs_write+0x128/0x26d<br /> ksys_write+0xac/0xfe<br /> do_syscall_64+0x9a/0xfd<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> The details of command execution process are as follows. In the above<br /> resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a<br /> top level resource. So, region_intersects() will report no System RAM<br /> resources in the CXL memory region incorrectly, because it only checks the<br /> top level resources. Consequently, devmem_is_allowed() will return 1<br /> (allow access via /dev/mem) for CXL memory region incorrectly. <br /> Fortunately, ioremap() doesn&amp;#39;t allow to map System RAM and reject the<br /> access.<br /> <br /> So, region_intersects() needs to be fixed to work correctly with the<br /> resource tree with "System RAM" not at top level as above. To fix it, if<br /> we found a unmatched resource in the top level, we will continue to search<br /> matched resources in its descendant resources. So, we will not miss any<br /> matched resources in resource tree anymore.<br /> <br /> In the new implementation, an example resource tree<br /> <br /> |------------- "CXL Window 0" ------------|<br /> |-- "System RAM" --|<br /> <br /> will behave similar as the following fake resource tree for<br /> region_intersects(, IORESOURCE_SYSTEM_RAM, ),<br /> <br /> |-- "System RAM" --||-- "CXL Window 0a" --|<br /> <br /> Where "CXL Window 0a" is part of the original "CXL Window 0" that<br /> isn&amp;#39;t covered by "System RAM".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: send: fix buffer overflow detection when copying path to cache entry<br /> <br /> Starting with commit c0247d289e73 ("btrfs: send: annotate struct<br /> name_cache_entry with __counted_by()") we annotated the variable length<br /> array "name" from the name_cache_entry structure with __counted_by() to<br /> improve overflow detection. However that alone was not correct, because<br /> the length of that array does not match the "name_len" field - it matches<br /> that plus 1 to include the NUL string terminator, so that makes a<br /> fortified kernel think there&amp;#39;s an overflow and report a splat like this:<br /> <br /> strcpy: detected buffer overflow: 20 byte write of buffer size 19<br /> WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50<br /> CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1<br /> Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018<br /> RIP: 0010:__fortify_report+0x45/0x50<br /> Code: 48 8b 34 (...)<br /> RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246<br /> RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027<br /> RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8<br /> RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd<br /> R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400<br /> R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8<br /> FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0<br /> Call Trace:<br /> <br /> ? __warn+0x12a/0x1d0<br /> ? __fortify_report+0x45/0x50<br /> ? report_bug+0x154/0x1c0<br /> ? handle_bug+0x42/0x70<br /> ? exc_invalid_op+0x1a/0x50<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? __fortify_report+0x45/0x50<br /> __fortify_panic+0x9/0x10<br /> __get_cur_name_and_parent+0x3bc/0x3c0<br /> get_cur_path+0x207/0x3b0<br /> send_extent_data+0x709/0x10d0<br /> ? find_parent_nodes+0x22df/0x25d0<br /> ? mas_nomem+0x13/0x90<br /> ? mtree_insert_range+0xa5/0x110<br /> ? btrfs_lru_cache_store+0x5f/0x1e0<br /> ? iterate_extent_inodes+0x52d/0x5a0<br /> process_extent+0xa96/0x11a0<br /> ? __pfx_lookup_backref_cache+0x10/0x10<br /> ? __pfx_store_backref_cache+0x10/0x10<br /> ? __pfx_iterate_backrefs+0x10/0x10<br /> ? __pfx_check_extent_item+0x10/0x10<br /> changed_cb+0x6fa/0x930<br /> ? tree_advance+0x362/0x390<br /> ? memcmp_extent_buffer+0xd7/0x160<br /> send_subvol+0xf0a/0x1520<br /> btrfs_ioctl_send+0x106b/0x11d0<br /> ? __pfx___clone_root_cmp_sort+0x10/0x10<br /> _btrfs_ioctl_send+0x1ac/0x240<br /> btrfs_ioctl+0x75b/0x850<br /> __se_sys_ioctl+0xca/0x150<br /> do_syscall_64+0x85/0x160<br /> ? __count_memcg_events+0x69/0x100<br /> ? handle_mm_fault+0x1327/0x15c0<br /> ? __se_sys_rt_sigprocmask+0xf1/0x180<br /> ? syscall_exit_to_user_mode+0x75/0xa0<br /> ? do_syscall_64+0x91/0x160<br /> ? do_user_addr_fault+0x21d/0x630<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fae145eeb4f<br /> Code: 00 48 89 (...)<br /> RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f<br /> RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004<br /> RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927<br /> R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8<br /> R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004<br /> <br /> <br /> Fix this by not storing the NUL string terminator since we don&amp;#39;t actually<br /> need it for name cache entries, this way "name_len" corresponds to the<br /> actual size of the "name" array. This requires marking the "name" array<br /> field with __nonstring and using memcpy() instead of strcpy() as<br /> recommended by the guidelines at:<br /> <br /> https://github.com/KSPP/linux/issues/90

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/gup: fix memfd_pin_folios alloc race panic<br /> <br /> If memfd_pin_folios tries to create a hugetlb page, but someone else<br /> already did, then folio gets the value -EEXIST here:<br /> <br /> folio = memfd_alloc_folio(memfd, start_idx);<br /> if (IS_ERR(folio)) {<br /> ret = PTR_ERR(folio);<br /> if (ret != -EEXIST)<br /> goto err;<br /> <br /> then on the next trip through the "while start_idx" loop we panic here:<br /> <br /> if (folio) {<br /> folio_put(folio);<br /> <br /> To fix, set the folio to NULL on error.