Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> time/debug: Fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic at<br /> once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: fotg210: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic<br /> at once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: gadget: gr_udc: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic<br /> at once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: dp: Only trigger DRM HPD events if bridge is attached<br /> <br /> The MediaTek DisplayPort interface bridge driver starts its interrupts<br /> as soon as its probed. However when the interrupts trigger the bridge<br /> might not have been attached to a DRM device. As drm_helper_hpd_irq_event()<br /> does not check whether the passed in drm_device is valid or not, a NULL<br /> pointer passed in results in a kernel NULL pointer dereference in it.<br /> <br /> Check whether the bridge is attached and only trigger an HPD event if<br /> it is.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: base: dd: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic<br /> at once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfs<br /> <br /> As the ramfs-based tmpfs uses ramfs_init_fs_context() for the<br /> init_fs_context method, which allocates fc-&gt;s_fs_info, use ramfs_kill_sb()<br /> to free it and avoid a memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix mlx5_ib_get_hw_stats when used for device<br /> <br /> Currently, when mlx5_ib_get_hw_stats() is used for device (port_num = 0),<br /> there is a special handling in order to use the correct counters, but,<br /> port_num is being passed down the stack without any change. Also, some<br /> functions assume that port_num &gt;=1. As a result, the following oops can<br /> occur.<br /> <br /> BUG: unable to handle page fault for address: ffff89510294f1a8<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0002 [#1] SMP<br /> CPU: 8 PID: 1382 Comm: devlink Tainted: G W 6.1.0-rc4_for_upstream_base_2022_11_10_16_12 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:_raw_spin_lock+0xc/0x20<br /> Call Trace:<br /> <br /> mlx5_ib_get_native_port_mdev+0x73/0xe0 [mlx5_ib]<br /> do_get_hw_stats.constprop.0+0x109/0x160 [mlx5_ib]<br /> mlx5_ib_get_hw_stats+0xad/0x180 [mlx5_ib]<br /> ib_setup_device_attrs+0xf0/0x290 [ib_core]<br /> ib_register_device+0x3bb/0x510 [ib_core]<br /> ? atomic_notifier_chain_register+0x67/0x80<br /> __mlx5_ib_add+0x2b/0x80 [mlx5_ib]<br /> mlx5r_probe+0xb8/0x150 [mlx5_ib]<br /> ? auxiliary_match_id+0x6a/0x90<br /> auxiliary_bus_probe+0x3c/0x70<br /> ? driver_sysfs_add+0x6b/0x90<br /> really_probe+0xcd/0x380<br /> __driver_probe_device+0x80/0x170<br /> driver_probe_device+0x1e/0x90<br /> __device_attach_driver+0x7d/0x100<br /> ? driver_allows_async_probing+0x60/0x60<br /> ? driver_allows_async_probing+0x60/0x60<br /> bus_for_each_drv+0x7b/0xc0<br /> __device_attach+0xbc/0x200<br /> bus_probe_device+0x87/0xa0<br /> device_add+0x404/0x940<br /> ? dev_set_name+0x53/0x70<br /> __auxiliary_device_add+0x43/0x60<br /> add_adev+0x99/0xe0 [mlx5_core]<br /> mlx5_attach_device+0xc8/0x120 [mlx5_core]<br /> mlx5_load_one_devl_locked+0xb2/0xe0 [mlx5_core]<br /> devlink_reload+0x133/0x250<br /> devlink_nl_cmd_reload+0x480/0x570<br /> ? devlink_nl_pre_doit+0x44/0x2b0<br /> genl_family_rcv_msg_doit.isra.0+0xc2/0x110<br /> genl_rcv_msg+0x180/0x2b0<br /> ? devlink_nl_cmd_region_read_dumpit+0x540/0x540<br /> ? devlink_reload+0x250/0x250<br /> ? devlink_put+0x50/0x50<br /> ? genl_family_rcv_msg_doit.isra.0+0x110/0x110<br /> netlink_rcv_skb+0x54/0x100<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x1f6/0x2c0<br /> netlink_sendmsg+0x237/0x490<br /> sock_sendmsg+0x33/0x40<br /> __sys_sendto+0x103/0x160<br /> ? handle_mm_fault+0x10e/0x290<br /> ? do_user_addr_fault+0x1c0/0x5f0<br /> __x64_sys_sendto+0x25/0x30<br /> do_syscall_64+0x3d/0x90<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Fix it by setting port_num to 1 in order to get device status and remove<br /> unused variable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: xsk: Fix crash on regular rq reactivation<br /> <br /> When the regular rq is reactivated after the XSK socket is closed<br /> it could be reading stale cqes which eventually corrupts the rq.<br /> This leads to no more traffic being received on the regular rq and a<br /> crash on the next close or deactivation of the rq.<br /> <br /> Kal Cuttler Conely reported this issue as a crash on the release<br /> path when the xdpsock sample program is stopped (killed) and restarted<br /> in sequence while traffic is running.<br /> <br /> This patch flushes all cqes when during the rq flush. The cqe flushing<br /> is done in the reset state of the rq. mlx5e_rq_to_ready code is moved<br /> into the flush function to allow for this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer<br /> <br /> ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5<br /> <br /> According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.<br /> <br /> When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.<br /> <br /> =============================================================<br /> UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type &amp;#39;union acpi_operand_object *[9]&amp;#39;<br /> CPU: 37 PID: 1678 Comm: cat Not tainted<br /> 6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k<br /> HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace:<br /> dump_backtrace+0xe0/0x130<br /> show_stack+0x20/0x60<br /> dump_stack_lvl+0x68/0x84<br /> dump_stack+0x18/0x34<br /> ubsan_epilogue+0x10/0x50<br /> __ubsan_handle_out_of_bounds+0x80/0x90<br /> acpi_ds_exec_end_op+0x1bc/0x6d8<br /> acpi_ps_parse_loop+0x57c/0x618<br /> acpi_ps_parse_aml+0x1e0/0x4b4<br /> acpi_ps_execute_method+0x24c/0x2b8<br /> acpi_ns_evaluate+0x3a8/0x4bc<br /> acpi_evaluate_object+0x15c/0x37c<br /> acpi_evaluate_integer+0x54/0x15c<br /> show_power+0x8c/0x12c [acpi_power_meter]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Fix memory leak in do_rename<br /> <br /> If renaming a file in an encrypted directory, function<br /> fscrypt_setup_filename allocates memory for a file name. This name is<br /> never used, and before returning to the caller the memory for it is not<br /> freed.<br /> <br /> When running kmemleak on it we see that it is registered as a leak. The<br /> report below is triggered by a simple program &amp;#39;rename&amp;#39; that renames a<br /> file in an encrypted directory:<br /> <br /> unreferenced object 0xffff888101502840 (size 32):<br /> comm "rename", pid 9404, jiffies 4302582475 (age 435.735s)<br /> backtrace:<br /> __kmem_cache_alloc_node<br /> __kmalloc<br /> fscrypt_setup_filename<br /> do_rename<br /> ubifs_rename<br /> vfs_rename<br /> do_renameat2<br /> <br /> To fix this we can remove the call to fscrypt_setup_filename as it&amp;#39;s not<br /> needed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> modpost: fix off by one in is_executable_section()<br /> <br /> The &gt; comparison should be &gt;= to prevent an out of bounds array<br /> access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: intel-ish-hid: Fix kernel panic during warm reset<br /> <br /> During warm reset device-&gt;fw_client is set to NULL. If a bus driver is<br /> registered after this NULL setting and before new firmware clients are<br /> enumerated by ISHTP, kernel panic will result in the function<br /> ishtp_cl_bus_match(). This is because of reference to<br /> device-&gt;fw_client-&gt;props.protocol_name.<br /> <br /> ISH firmware after getting successfully loaded, sends a warm reset<br /> notification to remove all clients from the bus and sets<br /> device-&gt;fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel<br /> module drivers were loaded right after any of the first ISHTP device was<br /> registered, regardless of whether it was a matched or an unmatched<br /> device. This resulted in all drivers getting registered much before the<br /> warm reset notification from ISH.<br /> <br /> Starting kernel v5.16, this issue got exposed after the change was<br /> introduced to load only bus drivers for the respective matching devices.<br /> In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are<br /> registered after the warm reset device fw_client NULL setting.<br /> cros_ec_ishtp driver_register() triggers the callback to<br /> ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel<br /> panic in guid_equal() when dereferencing fw_client NULL pointer to get<br /> protocol_name.