Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa: ifcvf: Do proper cleanup if IFCVF init fails<br /> <br /> ifcvf_mgmt_dev leaks memory if it is not freed before<br /> returning. Call is made to correct return statement<br /> so memory does not leak. ifcvf_init_hw does not take<br /> care of this so it is needed to do it here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/region: Fix null pointer dereference for resetting decoder<br /> <br /> Not all decoders have a reset callback.<br /> <br /> The CXL specification allows a host bridge with a single root port to<br /> have no explicit HDM decoders. Currently the region driver assumes there<br /> are none. As such the CXL core creates a special pass through decoder<br /> instance without a commit/reset callback.<br /> <br /> Prior to this patch, the -&gt;reset() callback was called unconditionally when<br /> calling cxl_region_decode_reset. Thus a configuration with 1 Host Bridge,<br /> 1 Root Port, and one directly attached CXL type 3 device or multiple CXL<br /> type 3 devices attached to downstream ports of a switch can cause a null<br /> pointer dereference.<br /> <br /> Before the fix, a kernel crash was observed when we destroy the region, and<br /> a pass through decoder is reset.<br /> <br /> The issue can be reproduced as below,<br /> 1) create a region with a CXL setup which includes a HB with a<br /> single root port under which a memdev is attached directly.<br /> 2) destroy the region with cxl destroy-region regionX -f.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: single: fix potential NULL dereference<br /> <br /> Added checking of pointer "function" in pcs_set_mux().<br /> pinmux_generic_get_function() can return NULL and the pointer<br /> "function" was dereferenced without checking against NULL.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: switch: fix potential memleak in ice_add_adv_recipe()<br /> <br /> When ice_add_special_words() fails, the &amp;#39;rm&amp;#39; is not released, which will<br /> lead to a memory leak. Fix this up by going to &amp;#39;err_unroll&amp;#39; label.<br /> <br /> Compile tested only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: fix a possible null pointer dereference<br /> <br /> In radeon_fp_native_mode(), the return value of drm_mode_duplicate()<br /> is assigned to mode, which will lead to a NULL pointer dereference<br /> on failure of drm_mode_duplicate(). Add a check to avoid npd.<br /> <br /> The failure status of drm_cvt_mode() on the other path is checked too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix kernel warning when sending SYN message<br /> <br /> When sending a SYN message, this kernel stack trace is observed:<br /> <br /> ...<br /> [ 13.396352] RIP: 0010:_copy_from_iter+0xb4/0x550<br /> ...<br /> [ 13.398494] Call Trace:<br /> [ 13.398630] <br /> [ 13.398630] ? __alloc_skb+0xed/0x1a0<br /> [ 13.398630] tipc_msg_build+0x12c/0x670 [tipc]<br /> [ 13.398630] ? shmem_add_to_page_cache.isra.71+0x151/0x290<br /> [ 13.398630] __tipc_sendmsg+0x2d1/0x710 [tipc]<br /> [ 13.398630] ? tipc_connect+0x1d9/0x230 [tipc]<br /> [ 13.398630] ? __local_bh_enable_ip+0x37/0x80<br /> [ 13.398630] tipc_connect+0x1d9/0x230 [tipc]<br /> [ 13.398630] ? __sys_connect+0x9f/0xd0<br /> [ 13.398630] __sys_connect+0x9f/0xd0<br /> [ 13.398630] ? preempt_count_add+0x4d/0xa0<br /> [ 13.398630] ? fpregs_assert_state_consistent+0x22/0x50<br /> [ 13.398630] __x64_sys_connect+0x16/0x20<br /> [ 13.398630] do_syscall_64+0x42/0x90<br /> [ 13.398630] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> It is because commit a41dad905e5a ("iov_iter: saner checks for attempt<br /> to copy to/from iterator") has introduced sanity check for copying<br /> from/to iov iterator. Lacking of copy direction from the iterator<br /> viewpoint would lead to kernel stack trace like above.<br /> <br /> This commit fixes this issue by initializing the iov iterator with<br /> the correct copy direction when sending SYN or ACK without data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: use a bounce buffer for copying skb-&gt;mark<br /> <br /> syzbot found arm64 builds would crash in sock_recv_mark()<br /> when CONFIG_HARDENED_USERCOPY=y<br /> <br /> x86 and powerpc are not detecting the issue because<br /> they define user_access_begin.<br /> This will be handled in a different patch,<br /> because a check_object_size() is missing.<br /> <br /> Only data from skb-&gt;cb[] can be copied directly to/from user space,<br /> as explained in commit 79a8a642bf05 ("net: Whitelist<br /> the skbuff_head_cache "cb" field")<br /> <br /> syzbot report was:<br /> usercopy: Kernel memory exposure attempt detected from SLUB object &amp;#39;skbuff_head_cache&amp;#39; (offset 168, size 4)!<br /> ------------[ cut here ]------------<br /> kernel BUG at mm/usercopy.c:102 !<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 0 PID: 4410 Comm: syz-executor533 Not tainted 6.2.0-rc7-syzkaller-17907-g2d3827b3f393 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : usercopy_abort+0x90/0x94 mm/usercopy.c:90<br /> lr : usercopy_abort+0x90/0x94 mm/usercopy.c:90<br /> sp : ffff80000fb9b9a0<br /> x29: ffff80000fb9b9b0 x28: ffff0000c6073400 x27: 0000000020001a00<br /> x26: 0000000000000014 x25: ffff80000cf52000 x24: fffffc0000000000<br /> x23: 05ffc00000000200 x22: fffffc000324bf80 x21: ffff0000c92fe1a8<br /> x20: 0000000000000001 x19: 0000000000000004 x18: 0000000000000000<br /> x17: 656a626f2042554c x16: ffff0000c6073dd0 x15: ffff80000dbd2118<br /> x14: ffff0000c6073400 x13: 00000000ffffffff x12: ffff0000c6073400<br /> x11: ff808000081bbb4c x10: 0000000000000000 x9 : 7b0572d7cc0ccf00<br /> x8 : 7b0572d7cc0ccf00 x7 : ffff80000bf650d4 x6 : 0000000000000000<br /> x5 : 0000000000000001 x4 : 0000000000000001 x3 : 0000000000000000<br /> x2 : ffff0001fefbff08 x1 : 0000000100000000 x0 : 000000000000006c<br /> Call trace:<br /> usercopy_abort+0x90/0x94 mm/usercopy.c:90<br /> __check_heap_object+0xa8/0x100 mm/slub.c:4761<br /> check_heap_object mm/usercopy.c:196 [inline]<br /> __check_object_size+0x208/0x6b8 mm/usercopy.c:251<br /> check_object_size include/linux/thread_info.h:199 [inline]<br /> __copy_to_user include/linux/uaccess.h:115 [inline]<br /> put_cmsg+0x408/0x464 net/core/scm.c:238<br /> sock_recv_mark net/socket.c:975 [inline]<br /> __sock_recv_cmsgs+0x1fc/0x248 net/socket.c:984<br /> sock_recv_cmsgs include/net/sock.h:2728 [inline]<br /> packet_recvmsg+0x2d8/0x678 net/packet/af_packet.c:3482<br /> ____sys_recvmsg+0x110/0x3a0<br /> ___sys_recvmsg net/socket.c:2737 [inline]<br /> __sys_recvmsg+0x194/0x210 net/socket.c:2767<br /> __do_sys_recvmsg net/socket.c:2777 [inline]<br /> __se_sys_recvmsg net/socket.c:2774 [inline]<br /> __arm64_sys_recvmsg+0x2c/0x3c net/socket.c:2774<br /> __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]<br /> invoke_syscall+0x64/0x178 arch/arm64/kernel/syscall.c:52<br /> el0_svc_common+0xbc/0x180 arch/arm64/kernel/syscall.c:142<br /> do_el0_svc+0x48/0x110 arch/arm64/kernel/syscall.c:193<br /> el0_svc+0x58/0x14c arch/arm64/kernel/entry-common.c:637<br /> el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655<br /> el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591<br /> Code: 91388800 aa0903e1 f90003e8 94e6d752 (d4210000)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: fix possible memory leak in ovs_meter_cmd_set()<br /> <br /> old_meter needs to be free after it is detached regardless of whether<br /> the new meter is successfully attached.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/usb: kalmia: Don&amp;#39;t pass act_len in usb_bulk_msg error path<br /> <br /> syzbot reported that act_len in kalmia_send_init_packet() is<br /> uninitialized when passing it to the first usb_bulk_msg error path. Jiri<br /> Pirko noted that it&amp;#39;s pointless to pass it in the error path, and that<br /> the value that would be printed in the second error path would be the<br /> value of act_len from the first call to usb_bulk_msg.[1]<br /> <br /> With this in mind, let&amp;#39;s just not pass act_len to the usb_bulk_msg error<br /> paths.<br /> <br /> 1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> freezer,umh: Fix call_usermode_helper_exec() vs SIGKILL<br /> <br /> Tetsuo-San noted that commit f5d39b020809 ("freezer,sched: Rewrite<br /> core freezer logic") broke call_usermodehelper_exec() for the KILLABLE<br /> case.<br /> <br /> Specifically it was missed that the second, unconditional,<br /> wait_for_completion() was not optional and ensures the on-stack<br /> completion is unused before going out-of-scope.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix underflow in second superblock position calculations<br /> <br /> Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second<br /> superblock, underflows when the argument device size is less than 4096<br /> bytes. Therefore, when using this macro, it is necessary to check in<br /> advance that the device size is not less than a lower limit, or at least<br /> that underflow does not occur.<br /> <br /> The current nilfs2 implementation lacks this check, causing out-of-bound<br /> block access when mounting devices smaller than 4096 bytes:<br /> <br /> I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0<br /> phys_seg 1 prio class 2<br /> NILFS (loop0): unable to read secondary superblock (blocksize = 1024)<br /> <br /> In addition, when trying to resize the filesystem to a size below 4096<br /> bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number<br /> of segments to nilfs_sufile_resize(), corrupting parameters such as the<br /> number of segments in superblocks. This causes excessive loop iterations<br /> in nilfs_sufile_resize() during a subsequent resize ioctl, causing<br /> semaphore ns_segctor_sem to block for a long time and hang the writer<br /> thread:<br /> <br /> INFO: task segctord:5067 blocked for more than 143 seconds.<br /> Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:segctord state:D stack:23456 pid:5067 ppid:2<br /> flags:0x00004000<br /> Call Trace:<br /> <br /> context_switch kernel/sched/core.c:5293 [inline]<br /> __schedule+0x1409/0x43f0 kernel/sched/core.c:6606<br /> schedule+0xc3/0x190 kernel/sched/core.c:6682<br /> rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190<br /> nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357<br /> nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline]<br /> nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570<br /> kthread+0x270/0x300 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308<br /> <br /> ...<br /> Call Trace:<br /> <br /> folio_mark_accessed+0x51c/0xf00 mm/swap.c:515<br /> __nilfs_get_page_block fs/nilfs2/page.c:42 [inline]<br /> nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61<br /> nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121<br /> nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176<br /> nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251<br /> nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline]<br /> nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline]<br /> nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777<br /> nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422<br /> nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline]<br /> nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301<br /> ...<br /> <br /> This fixes these issues by inserting appropriate minimum device size<br /> checks or anti-underflow checks, depending on where the macro is used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: sim: fix a memory leak<br /> <br /> Fix an inverted logic bug in gpio_sim_remove_hogs() that leads to GPIO<br /> hog structures never being freed.