Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix NULL pointer dereference in smb2_get_info_filesystem()<br /> <br /> If share is , share-&gt;path is NULL and it cause NULL pointer<br /> dereference issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda: Fix Oops by 9.1 surround channel names<br /> <br /> get_line_out_pfx() may trigger an Oops by overflowing the static array<br /> with more than 8 channels. This was reported for MacBookPro 12,1 with<br /> Cirrus codec.<br /> <br /> As a workaround, extend for the 9.1 channels and also fix the<br /> potential Oops by unifying the code paths accessing the same array<br /> with the proper size check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: kmem: fix a NULL pointer dereference in obj_stock_flush_required()<br /> <br /> KCSAN found an issue in obj_stock_flush_required():<br /> stock-&gt;cached_objcg can be reset between the check and dereference:<br /> <br /> ==================================================================<br /> BUG: KCSAN: data-race in drain_all_stock / drain_obj_stock<br /> <br /> write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0:<br /> drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306<br /> refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340<br /> obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408<br /> memcg_slab_free_hook mm/slab.h:587 [inline]<br /> __cache_free mm/slab.c:3373 [inline]<br /> __do_kmem_cache_free mm/slab.c:3577 [inline]<br /> kmem_cache_free+0x105/0x280 mm/slab.c:3602<br /> __d_free fs/dcache.c:298 [inline]<br /> dentry_free fs/dcache.c:375 [inline]<br /> __dentry_kill+0x422/0x4a0 fs/dcache.c:621<br /> dentry_kill+0x8d/0x1e0<br /> dput+0x118/0x1f0 fs/dcache.c:913<br /> __fput+0x3bf/0x570 fs/file_table.c:329<br /> ____fput+0x15/0x20 fs/file_table.c:349<br /> task_work_run+0x123/0x160 kernel/task_work.c:179<br /> resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]<br /> exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171<br /> exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]<br /> syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296<br /> do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1:<br /> obj_stock_flush_required mm/memcontrol.c:3319 [inline]<br /> drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361<br /> try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703<br /> try_charge mm/memcontrol.c:2837 [inline]<br /> mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290<br /> sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025<br /> sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525<br /> udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692<br /> udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817<br /> sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668<br /> __sys_setsockopt+0x1c3/0x230 net/socket.c:2271<br /> __do_sys_setsockopt net/socket.c:2282 [inline]<br /> __se_sys_setsockopt net/socket.c:2279 [inline]<br /> __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0xffff8881382d52c0 -&gt; 0xffff888138893740<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023<br /> <br /> Fix it by using READ_ONCE()/WRITE_ONCE() for all accesses to<br /> stock-&gt;cached_objcg.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernel/printk/index.c: 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 /> 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 /> 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.

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.