Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: isp116x: 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: snic: 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: gadget: pxa25x_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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlx5: fix possible ptp queue fifo use-after-free<br /> <br /> Fifo indexes are not checked during pop operations and it leads to<br /> potential use-after-free when poping from empty queue. Such case was<br /> possible during re-sync action. WARN_ON_ONCE covers future cases.<br /> <br /> There were out-of-order cqe spotted which lead to drain of the queue and<br /> use-after-free because of lack of fifo pointers check. Special check and<br /> counter are added to avoid resync operation if SKB could not exist in the<br /> fifo because of OOO cqe (skb_id must be between consumer and producer<br /> index).

*** Pendiente de traducción *** 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.