Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_router: Fix neighbour use-after-free<br /> <br /> We sometimes observe use-after-free when dereferencing a neighbour [1].<br /> The problem seems to be that the driver stores a pointer to the<br /> neighbour, but without holding a reference on it. A reference is only<br /> taken when the neighbour is used by a nexthop.<br /> <br /> Fix by simplifying the reference counting scheme. Always take a<br /> reference when storing a neighbour pointer in a neighbour entry. Avoid<br /> taking a referencing when the neighbour is used by a nexthop as the<br /> neighbour entry associated with the nexthop already holds a reference.<br /> <br /> Tested by running the test that uncovered the problem over 300 times.<br /> Without this patch the problem was reproduced after a handful of<br /> iterations.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310<br /> Read of size 8 at addr ffff88817f8e3420 by task ip/3929<br /> <br /> CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)<br /> Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6f/0xa0<br /> print_address_description.constprop.0+0x6e/0x300<br /> print_report+0xfc/0x1fb<br /> kasan_report+0xe4/0x110<br /> mlxsw_sp_neigh_entry_update+0x2d4/0x310<br /> mlxsw_sp_router_rif_gone_sync+0x35f/0x510<br /> mlxsw_sp_rif_destroy+0x1ea/0x730<br /> mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0<br /> __mlxsw_sp_inetaddr_lag_event+0xcc/0x130<br /> __mlxsw_sp_inetaddr_event+0xf5/0x3c0<br /> mlxsw_sp_router_netdevice_event+0x1015/0x1580<br /> notifier_call_chain+0xcc/0x150<br /> call_netdevice_notifiers_info+0x7e/0x100<br /> __netdev_upper_dev_unlink+0x10b/0x210<br /> netdev_upper_dev_unlink+0x79/0xa0<br /> vrf_del_slave+0x18/0x50<br /> do_set_master+0x146/0x7d0<br /> do_setlink.isra.0+0x9a0/0x2880<br /> rtnl_newlink+0x637/0xb20<br /> rtnetlink_rcv_msg+0x6fe/0xb90<br /> netlink_rcv_skb+0x123/0x380<br /> netlink_unicast+0x4a3/0x770<br /> netlink_sendmsg+0x75b/0xc90<br /> __sock_sendmsg+0xbe/0x160<br /> ____sys_sendmsg+0x5b2/0x7d0<br /> ___sys_sendmsg+0xfd/0x180<br /> __sys_sendmsg+0x124/0x1c0<br /> do_syscall_64+0xbb/0xfd0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> [...]<br /> <br /> Allocated by task 109:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x7b/0x90<br /> __kmalloc_noprof+0x2c1/0x790<br /> neigh_alloc+0x6af/0x8f0<br /> ___neigh_create+0x63/0xe90<br /> mlxsw_sp_nexthop_neigh_init+0x430/0x7e0<br /> mlxsw_sp_nexthop_type_init+0x212/0x960<br /> mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280<br /> mlxsw_sp_nexthop6_group_get+0x392/0x6a0<br /> mlxsw_sp_fib6_entry_create+0x46a/0xfd0<br /> mlxsw_sp_router_fib6_replace+0x1ed/0x5f0<br /> mlxsw_sp_router_fib6_event_work+0x10a/0x2a0<br /> process_one_work+0xd57/0x1390<br /> worker_thread+0x4d6/0xd40<br /> kthread+0x355/0x5b0<br /> ret_from_fork+0x1d4/0x270<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Freed by task 154:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x43/0x70<br /> kmem_cache_free_bulk.part.0+0x1eb/0x5e0<br /> kvfree_rcu_bulk+0x1f2/0x260<br /> kfree_rcu_work+0x130/0x1b0<br /> process_one_work+0xd57/0x1390<br /> worker_thread+0x4d6/0xd40<br /> kthread+0x355/0x5b0<br /> ret_from_fork+0x1d4/0x270<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x30/0x50<br /> kasan_record_aux_stack+0x8c/0xa0<br /> kvfree_call_rcu+0x93/0x5b0<br /> mlxsw_sp_router_neigh_event_work+0x67d/0x860<br /> process_one_work+0xd57/0x1390<br /> worker_thread+0x4d6/0xd40<br /> kthread+0x355/0x5b0<br /> ret_from_fork+0x1d4/0x270<br /> ret_from_fork_asm+0x11/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Limit num_syncs to prevent oversized allocations<br /> <br /> The exec and vm_bind ioctl allow userspace to specify an arbitrary<br /> num_syncs value. Without bounds checking, a very large num_syncs<br /> can force an excessively large allocation, leading to kernel warnings<br /> from the page allocator as below.<br /> <br /> Introduce DRM_XE_MAX_SYNCS (set to 1024) and reject any request<br /> exceeding this limit.<br /> <br /> "<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 1217 at mm/page_alloc.c:5124 __alloc_frozen_pages_noprof+0x2f8/0x2180 mm/page_alloc.c:5124<br /> ...<br /> Call Trace:<br /> <br /> alloc_pages_mpol+0xe4/0x330 mm/mempolicy.c:2416<br /> ___kmalloc_large_node+0xd8/0x110 mm/slub.c:4317<br /> __kmalloc_large_node_noprof+0x18/0xe0 mm/slub.c:4348<br /> __do_kmalloc_node mm/slub.c:4364 [inline]<br /> __kmalloc_noprof+0x3d4/0x4b0 mm/slub.c:4388<br /> kmalloc_noprof include/linux/slab.h:909 [inline]<br /> kmalloc_array_noprof include/linux/slab.h:948 [inline]<br /> xe_exec_ioctl+0xa47/0x1e70 drivers/gpu/drm/xe/xe_exec.c:158<br /> drm_ioctl_kernel+0x1f1/0x3e0 drivers/gpu/drm/drm_ioctl.c:797<br /> drm_ioctl+0x5e7/0xc50 drivers/gpu/drm/drm_ioctl.c:894<br /> xe_drm_ioctl+0x10b/0x170 drivers/gpu/drm/xe/xe_device.c:224<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:598 [inline]<br /> __se_sys_ioctl fs/ioctl.c:584 [inline]<br /> __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:584<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xbb/0x380 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> ...<br /> "<br /> <br /> v2: Add "Reported-by" and Cc stable kernels.<br /> v3: Change XE_MAX_SYNCS from 64 to 1024. (Matt &amp; Ashutosh)<br /> v4: s/XE_MAX_SYNCS/DRM_XE_MAX_SYNCS/ (Matt)<br /> v5: Do the check at the top of the exec func. (Matt)<br /> <br /> (cherry picked from commit b07bac9bd708ec468cd1b8a5fe70ae2ac9b0a11c)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: NFSv4 file creation neglects setting ACL<br /> <br /> An NFSv4 client that sets an ACL with a named principal during file<br /> creation retrieves the ACL afterwards, and finds that it is only a<br /> default ACL (based on the mode bits) and not the ACL that was<br /> requested during file creation. This violates RFC 8881 section<br /> 6.4.1.3: "the ACL attribute is set as given".<br /> <br /> The issue occurs in nfsd_create_setattr(), which calls<br /> nfsd_attrs_valid() to determine whether to call nfsd_setattr().<br /> However, nfsd_attrs_valid() checks only for iattr changes and<br /> security labels, but not POSIX ACLs. When only an ACL is present,<br /> the function returns false, nfsd_setattr() is skipped, and the<br /> POSIX ACL is never applied to the inode.<br /> <br /> Subsequently, when the client retrieves the ACL, the server finds<br /> no POSIX ACL on the inode and returns one generated from the file&amp;#39;s<br /> mode bits rather than returning the originally-specified ACL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/chrome: cros_ec_ishtp: Fix UAF after unbinding driver<br /> <br /> After unbinding the driver, another kthread `cros_ec_console_log_work`<br /> is still accessing the device, resulting an UAF and crash.<br /> <br /> The driver doesn&amp;#39;t unregister the EC device in .remove() which should<br /> shutdown sub-devices synchronously. Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: fix io-uring list corruption for terminated non-committed requests<br /> <br /> When a request is terminated before it has been committed, the request<br /> is not removed from the queue&amp;#39;s list. This leaves a dangling list entry<br /> that leads to list corruption and use-after-free issues.<br /> <br /> Remove the request from the queue&amp;#39;s list for terminated non-committed<br /> requests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix buffer validation by including null terminator size in EA length<br /> <br /> The smb2_set_ea function, which handles Extended Attributes (EA),<br /> was performing buffer validation checks that incorrectly omitted the size<br /> of the null terminating character (+1 byte) for EA Name.<br /> This patch fixes the issue by explicitly adding &amp;#39;+ 1&amp;#39; to EaNameLength where<br /> the null terminator is expected to be present in the buffer, ensuring<br /> the validation accurately reflects the total required buffer size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix race between wbt_enable_default and IO submission<br /> <br /> When wbt_enable_default() is moved out of queue freezing in elevator_change(),<br /> it can cause the wbt inflight counter to become negative (-1), leading to hung<br /> tasks in the writeback path. Tasks get stuck in wbt_wait() because the counter<br /> is in an inconsistent state.<br /> <br /> The issue occurs because wbt_enable_default() could race with IO submission,<br /> allowing the counter to be decremented before proper initialization. This manifests<br /> as:<br /> <br /> rq_wait[0]:<br /> inflight: -1<br /> has_waiters: True<br /> <br /> rwb_enabled() checks the state, which can be updated exactly between wbt_wait()<br /> (rq_qos_throttle()) and wbt_track()(rq_qos_track()), then the inflight counter<br /> will become negative.<br /> <br /> And results in hung task warnings like:<br /> task:kworker/u24:39 state:D stack:0 pid:14767<br /> Call Trace:<br /> rq_qos_wait+0xb4/0x150<br /> wbt_wait+0xa9/0x100<br /> __rq_qos_throttle+0x24/0x40<br /> blk_mq_submit_bio+0x672/0x7b0<br /> ...<br /> <br /> Fix this by:<br /> <br /> 1. Splitting wbt_enable_default() into:<br /> - __wbt_enable_default(): Returns true if wbt_init() should be called<br /> - wbt_enable_default(): Wrapper for existing callers (no init)<br /> - wbt_init_enable_default(): New function that checks and inits WBT<br /> <br /> 2. Using wbt_init_enable_default() in blk_register_queue() to ensure<br /> proper initialization during queue registration<br /> <br /> 3. Move wbt_init() out of wbt_enable_default() which is only for enabling<br /> disabled wbt from bfq and iocost, and wbt_init() isn&amp;#39;t needed. Then the<br /> original lock warning can be avoided.<br /> <br /> 4. Removing the ELEVATOR_FLAG_ENABLE_WBT_ON_EXIT flag and its handling<br /> code since it&amp;#39;s no longer needed<br /> <br /> This ensures WBT is properly initialized before any IO can be submitted,<br /> preventing the counter from going negative.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: initialize local pointers upon transfer of memory ownership<br /> <br /> vidtv_channel_si_init() creates a temporary list (program, service, event)<br /> and ownership of the memory itself is transferred to the PAT/SDT/EIT<br /> tables through vidtv_psi_pat_program_assign(),<br /> vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign().<br /> <br /> The problem here is that the local pointer where the memory ownership<br /> transfer was completed is not initialized to NULL. This causes the<br /> vidtv_psi_pmt_create_sec_for_each_pat_entry() function to fail, and<br /> in the flow that jumps to free_eit, the memory that was freed by<br /> vidtv_psi_*_table_destroy() can be accessed again by<br /> vidtv_psi_*_event_destroy() due to the uninitialized local pointer, so it<br /> is freed once again.<br /> <br /> Therefore, to prevent use-after-free and double-free vulnerability,<br /> local pointers must be initialized to NULL when transferring memory<br /> ownership.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm2-sessions: Fix out of range indexing in name_size<br /> <br /> &amp;#39;name_size&amp;#39; does not have any range checks, and it just directly indexes<br /> with TPM_ALG_ID, which could lead into memory corruption at worst.<br /> <br /> Address the issue by only processing known values and returning -EINVAL for<br /> unrecognized values.<br /> <br /> Make also &amp;#39;tpm_buf_append_name&amp;#39; and &amp;#39;tpm_buf_fill_hmac_session&amp;#39; fallible so<br /> that errors are detected before causing any spurious TPM traffic.<br /> <br /> End also the authorization session on failure in both of the functions, as<br /> the session state would be then by definition corrupted.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix a job-&gt;pasid access race in gpu recovery<br /> <br /> Avoid a possible UAF in GPU recovery due to a race between<br /> the sched timeout callback and the tdr work queue.<br /> <br /> The gpu recovery function calls drm_sched_stop() and<br /> later drm_sched_start(). drm_sched_start() restarts<br /> the tdr queue which will eventually free the job. If<br /> the tdr queue frees the job before time out callback<br /> completes, the job will be freed and we&amp;#39;ll get a UAF<br /> when accessing the pasid. Cache it early to avoid the<br /> UAF.<br /> <br /> Example KASAN trace:<br /> [ 493.058141] BUG: KASAN: slab-use-after-free in amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.067530] Read of size 4 at addr ffff88b0ce3f794c by task kworker/u128:1/323<br /> [ 493.074892]<br /> [ 493.076485] CPU: 9 UID: 0 PID: 323 Comm: kworker/u128:1 Tainted: G E 6.16.0-1289896.2.zuul.bf4f11df81c1410bbe901c4373305a31 #1 PREEMPT(voluntary)<br /> [ 493.076493] Tainted: [E]=UNSIGNED_MODULE<br /> [ 493.076495] Hardware name: TYAN B8021G88V2HR-2T/S8021GM2NR-2T, BIOS V1.03.B10 04/01/2019<br /> [ 493.076500] Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched]<br /> [ 493.076512] Call Trace:<br /> [ 493.076515] <br /> [ 493.076518] dump_stack_lvl+0x64/0x80<br /> [ 493.076529] print_report+0xce/0x630<br /> [ 493.076536] ? _raw_spin_lock_irqsave+0x86/0xd0<br /> [ 493.076541] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 493.076545] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.077253] kasan_report+0xb8/0xf0<br /> [ 493.077258] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.077965] amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.078672] ? __pfx_amdgpu_device_gpu_recover+0x10/0x10 [amdgpu]<br /> [ 493.079378] ? amdgpu_coredump+0x1fd/0x4c0 [amdgpu]<br /> [ 493.080111] amdgpu_job_timedout+0x642/0x1400 [amdgpu]<br /> [ 493.080903] ? pick_task_fair+0x24e/0x330<br /> [ 493.080910] ? __pfx_amdgpu_job_timedout+0x10/0x10 [amdgpu]<br /> [ 493.081702] ? _raw_spin_lock+0x75/0xc0<br /> [ 493.081708] ? __pfx__raw_spin_lock+0x10/0x10<br /> [ 493.081712] drm_sched_job_timedout+0x1b0/0x4b0 [gpu_sched]<br /> [ 493.081721] ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> [ 493.081725] process_one_work+0x679/0xff0<br /> [ 493.081732] worker_thread+0x6ce/0xfd0<br /> [ 493.081736] ? __pfx_worker_thread+0x10/0x10<br /> [ 493.081739] kthread+0x376/0x730<br /> [ 493.081744] ? __pfx_kthread+0x10/0x10<br /> [ 493.081748] ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> [ 493.081751] ? __pfx_kthread+0x10/0x10<br /> [ 493.081755] ret_from_fork+0x247/0x330<br /> [ 493.081761] ? __pfx_kthread+0x10/0x10<br /> [ 493.081764] ret_from_fork_asm+0x1a/0x30<br /> [ 493.081771] <br /> <br /> (cherry picked from commit 20880a3fd5dd7bca1a079534cf6596bda92e107d)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iomap: adjust read range correctly for non-block-aligned positions<br /> <br /> iomap_adjust_read_range() assumes that the position and length passed in<br /> are block-aligned. This is not always the case however, as shown in the<br /> syzbot generated case for erofs. This causes too many bytes to be<br /> skipped for uptodate blocks, which results in returning the incorrect<br /> position and length to read in. If all the blocks are uptodate, this<br /> underflows length and returns a position beyond the folio.<br /> <br /> Fix the calculation to also take into account the block offset when<br /> calculating how many bytes can be skipped for uptodate blocks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: Avoid overflowing userspace buffer on stats query<br /> <br /> The ethtool -S command operates across three ioctl calls:<br /> ETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, and<br /> ETHTOOL_GSTATS for the values.<br /> <br /> If the number of stats changes between these calls (e.g., due to device<br /> reconfiguration), userspace&amp;#39;s buffer allocation will be incorrect,<br /> potentially leading to buffer overflow.<br /> <br /> Drivers are generally expected to maintain stable stat counts, but some<br /> drivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, making<br /> this scenario possible.<br /> <br /> Some drivers try to handle this internally:<br /> - bnad_get_ethtool_stats() returns early in case stats.n_stats is not<br /> equal to the driver&amp;#39;s stats count.<br /> - micrel/ksz884x also makes sure not to write anything beyond<br /> stats.n_stats and overflow the buffer.<br /> <br /> However, both use stats.n_stats which is already assigned with the value<br /> returned from get_sset_count(), hence won&amp;#39;t solve the issue described<br /> here.<br /> <br /> Change ethtool_get_strings(), ethtool_get_stats(),<br /> ethtool_get_phy_stats() to not return anything in case of a mismatch<br /> between userspace&amp;#39;s size and get_sset_size(), to prevent buffer<br /> overflow.<br /> The returned n_stats value will be equal to zero, to reflect that<br /> nothing has been returned.<br /> <br /> This could result in one of two cases when using upstream ethtool,<br /> depending on when the size change is detected:<br /> 1. When detected in ethtool_get_strings():<br /> # ethtool -S eth2<br /> no stats available<br /> <br /> 2. When detected in get stats, all stats will be reported as zero.<br /> <br /> Both cases are presumably transient, and a subsequent ethtool call<br /> should succeed.<br /> <br /> Other than the overflow avoidance, these two cases are very evident (no<br /> output/cleared stats), which is arguably better than presenting<br /> incorrect/shifted stats.<br /> I also considered returning an error instead of a "silent" response, but<br /> that seems more destructive towards userspace apps.<br /> <br /> Notes:<br /> - This patch does not claim to fix the inherent race, it only makes sure<br /> that we do not overflow the userspace buffer, and makes for a more<br /> predictable behavior.<br /> <br /> - RTNL lock is held during each ioctl, the race window exists between<br /> the separate ioctl calls when the lock is released.<br /> <br /> - Userspace ethtool always fills stats.n_stats, but it is likely that<br /> these stats ioctls are implemented in other userspace applications<br /> which might not fill it. The added code checks that it&amp;#39;s not zero,<br /> to prevent any regressions.