Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: gadget: bcm63xx_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 /> 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.

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.

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).

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.