Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()<br /> <br /> nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites<br /> fp-&gt;fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if<br /> the client already has a SHARE_ACCESS_READ open from a previous OPEN<br /> operation, this action overwrites the existing pointer without<br /> releasing its reference, orphaning the previous reference.<br /> <br /> Additionally, the function originally stored the same nfsd_file<br /> pointer in both fp-&gt;fi_fds[O_RDONLY] and fp-&gt;fi_rdeleg_file with<br /> only a single reference. When put_deleg_file() runs, it clears<br /> fi_rdeleg_file and calls nfs4_file_put_access() to release the file.<br /> <br /> However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when<br /> the fi_access[O_RDONLY] counter drops to zero. If another READ open<br /> exists on the file, the counter remains elevated and the nfsd_file<br /> reference from the delegation is never released. This potentially<br /> causes open conflicts on that file.<br /> <br /> Then, on server shutdown, these leaks cause __nfsd_file_cache_purge()<br /> to encounter files with an elevated reference count that cannot be<br /> cleaned up, ultimately triggering a BUG() in kmem_cache_destroy()<br /> because there are still nfsd_file objects allocated in that cache.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> team: fix check for port enabled in team_queue_override_port_prio_changed()<br /> <br /> There has been a syzkaller bug reported recently with the following<br /> trace:<br /> <br /> list_del corruption, ffff888058bea080-&gt;prev is LIST_POISON2 (dead000000000122)<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:59!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59<br /> Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff<br /> RSP: 0018:ffffc9000d49f370 EFLAGS: 00010286<br /> RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000<br /> RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005<br /> RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230<br /> R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480<br /> FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> __list_del_entry_valid include/linux/list.h:132 [inline]<br /> __list_del_entry include/linux/list.h:223 [inline]<br /> list_del_rcu include/linux/rculist.h:178 [inline]<br /> __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline]<br /> __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline]<br /> team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline]<br /> team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534<br /> team_option_set drivers/net/team/team_core.c:376 [inline]<br /> team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653<br /> genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115<br /> genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]<br /> genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210<br /> netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552<br /> genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]<br /> netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346<br /> netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630<br /> ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684<br /> __sys_sendmsg+0x16d/0x220 net/socket.c:2716<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> The problem is in this flow:<br /> 1) Port is enabled, queue_id != 0, in qom_list<br /> 2) Port gets disabled<br /> -&gt; team_port_disable()<br /> -&gt; team_queue_override_port_del()<br /> -&gt; del (removed from list)<br /> 3) Port is disabled, queue_id != 0, not in any list<br /> 4) Priority changes<br /> -&gt; team_queue_override_port_prio_changed()<br /> -&gt; checks: port disabled &amp;&amp; queue_id != 0<br /> -&gt; calls del - hits the BUG as it is removed already<br /> <br /> To fix this, change the check in team_queue_override_port_prio_changed()<br /> so it returns early if port is not enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/bnxt_re: Fix OOB write in bnxt_re_copy_err_stats()<br /> <br /> Commit ef56081d1864 ("RDMA/bnxt_re: RoCE related hardware counters<br /> update") added three new counters and placed them after<br /> BNXT_RE_OUT_OF_SEQ_ERR.<br /> <br /> BNXT_RE_OUT_OF_SEQ_ERR acts as a boundary marker for allocating hardware<br /> statistics with different num_counters values on chip_gen_p5_p7 devices.<br /> <br /> As a result, BNXT_RE_NUM_STD_COUNTERS are used when allocating<br /> hw_stats, which leads to an out-of-bounds write in<br /> bnxt_re_copy_err_stats().<br /> <br /> The counters BNXT_RE_REQ_CQE_ERROR, BNXT_RE_RESP_CQE_ERROR, and<br /> BNXT_RE_RESP_REMOTE_ACCESS_ERRS are applicable to generic hardware, not<br /> only p5/p7 devices.<br /> <br /> Fix this by moving these counters before BNXT_RE_OUT_OF_SEQ_ERR so they<br /> are included in the generic counter set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/oa: Limit num_syncs to prevent oversized allocations<br /> <br /> The OA open parameters did not validate num_syncs, allowing<br /> userspace to pass arbitrarily large values, potentially<br /> leading to excessive allocations.<br /> <br /> Add check to ensure that num_syncs does not exceed DRM_XE_MAX_SYNCS,<br /> returning -EINVAL when the limit is violated.<br /> <br /> v2: use XE_IOCTL_DBG() and drop duplicated check. (Ashutosh)<br /> <br /> (cherry picked from commit e057b2d2b8d815df3858a87dffafa2af37e5945b)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: Cap the number of PCR banks<br /> <br /> tpm2_get_pcr_allocation() does not cap any upper limit for the number of<br /> banks. Cap the limit to eight banks so that out of bounds values coming<br /> from external I/O cause on only limited harm.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write<br /> <br /> A deadlock can occur between nfc_unregister_device() and rfkill_fop_write()<br /> due to lock ordering inversion between device_lock and rfkill_global_mutex.<br /> <br /> The problematic lock order is:<br /> <br /> Thread A (rfkill_fop_write):<br /> rfkill_fop_write()<br /> mutex_lock(&amp;rfkill_global_mutex)<br /> rfkill_set_block()<br /> nfc_rfkill_set_block()<br /> nfc_dev_down()<br /> device_lock(&amp;dev-&gt;dev) dev)<br /> rfkill_unregister()<br /> mutex_lock(&amp;rfkill_global_mutex) <br /> rfkill_global_mutex via rfkill_register) is safe because during<br /> registration the device is not yet in rfkill_list, so no concurrent<br /> rfkill operations can occur on this device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix a BUG in rt6_get_pcpu_route() under PREEMPT_RT<br /> <br /> On PREEMPT_RT kernels, after rt6_get_pcpu_route() returns NULL, the<br /> current task can be preempted. Another task running on the same CPU<br /> may then execute rt6_make_pcpu_route() and successfully install a<br /> pcpu_rt entry. When the first task resumes execution, its cmpxchg()<br /> in rt6_make_pcpu_route() will fail because rt6i_pcpu is no longer<br /> NULL, triggering the BUG_ON(prev). It&amp;#39;s easy to reproduce it by adding<br /> mdelay() after rt6_get_pcpu_route().<br /> <br /> Using preempt_disable/enable is not appropriate here because<br /> ip6_rt_pcpu_alloc() may sleep.<br /> <br /> Fix this by handling the cmpxchg() failure gracefully on PREEMPT_RT:<br /> free our allocation and return the existing pcpu_rt installed by<br /> another task. The BUG_ON is replaced by WARN_ON_ONCE for non-PREEMPT_RT<br /> kernels where such races should not occur.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: stm32: sai: fix OF node leak on probe<br /> <br /> The reference taken to the sync provider OF node when probing the<br /> platform device is currently only dropped if the set_sync() callback<br /> fails during DAI probe.<br /> <br /> Make sure to drop the reference on platform probe failures (e.g. probe<br /> deferral) and on driver unbind.<br /> <br /> This also avoids a potential use-after-free in case the DAI is ever<br /> reprobed without first rebinding the platform driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: revert use of devm_kzalloc in btusb<br /> <br /> This reverts commit 98921dbd00c4e ("Bluetooth: Use devm_kzalloc in<br /> btusb.c file").<br /> <br /> In btusb_probe(), we use devm_kzalloc() to allocate the btusb data. This<br /> ties the lifetime of all the btusb data to the binding of a driver to<br /> one interface, INTF. In a driver that binds to other interfaces, ISOC<br /> and DIAG, this is an accident waiting to happen.<br /> <br /> The issue is revealed in btusb_disconnect(), where calling<br /> usb_driver_release_interface(&amp;btusb_driver, data-&gt;intf) will have devm<br /> free the data that is also being used by the other interfaces of the<br /> driver that may not be released yet.<br /> <br /> To fix this, revert the use of devm and go back to freeing memory<br /> explicitly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: Avoid NULL pointer deref for evicted BOs<br /> <br /> It is possible for a BO to exist that is not currently associated with a<br /> resource, e.g. because it has been evicted.<br /> <br /> When devcoredump tries to read the contents of all BOs for dumping, we need<br /> to expect this as well -- in this case, ENODATA is recorded instead of the<br /> buffer contents.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/64s/slb: Fix SLB multihit issue during SLB preload<br /> <br /> On systems using the hash MMU, there is a software SLB preload cache that<br /> mirrors the entries loaded into the hardware SLB buffer. This preload<br /> cache is subject to periodic eviction — typically after every 256 context<br /> switches — to remove old entry.<br /> <br /> To optimize performance, the kernel skips switch_mmu_context() in<br /> switch_mm_irqs_off() when the prev and next mm_struct are the same.<br /> However, on hash MMU systems, this can lead to inconsistencies between<br /> the hardware SLB and the software preload cache.<br /> <br /> If an SLB entry for a process is evicted from the software cache on one<br /> CPU, and the same process later runs on another CPU without executing<br /> switch_mmu_context(), the hardware SLB may retain stale entries. If the<br /> kernel then attempts to reload that entry, it can trigger an SLB<br /> multi-hit error.<br /> <br /> The following timeline shows how stale SLB entries are created and can<br /> cause a multi-hit error when a process moves between CPUs without a<br /> MMU context switch.<br /> <br /> CPU 0 CPU 1<br /> ----- -----<br /> Process P<br /> exec swapper/1<br /> load_elf_binary<br /> begin_new_exc<br /> activate_mm<br /> switch_mm_irqs_off<br /> switch_mmu_context<br /> switch_slb<br /> /*<br /> * This invalidates all<br /> * the entries in the HW<br /> * and setup the new HW<br /> * SLB entries as per the<br /> * preload cache.<br /> */<br /> context_switch<br /> sched_migrate_task migrates process P to cpu-1<br /> <br /> Process swapper/0 context switch (to process P)<br /> (uses mm_struct of Process P) switch_mm_irqs_off()<br /> switch_slb<br /> load_slb++<br /> /*<br /> * load_slb becomes 0 here<br /> * and we evict an entry from<br /> * the preload cache with<br /> * preload_age(). We still<br /> * keep HW SLB and preload<br /> * cache in sync, that is<br /> * because all HW SLB entries<br /> * anyways gets evicted in<br /> * switch_slb during SLBIA.<br /> * We then only add those<br /> * entries back in HW SLB,<br /> * which are currently<br /> * present in preload_cache<br /> * (after eviction).<br /> */<br /> load_elf_binary continues...<br /> setup_new_exec()<br /> slb_setup_new_exec()<br /> <br /> sched_switch event<br /> sched_migrate_task migrates<br /> process P to cpu-0<br /> <br /> context_switch from swapper/0 to Process P<br /> switch_mm_irqs_off()<br /> /*<br /> * Since both prev and next mm struct are same we don&amp;#39;t call<br /> * switch_mmu_context(). This will cause the HW SLB and SW preload<br /> * cache to go out of sync in preload_new_slb_context. Because there<br /> * was an SLB entry which was evicted from both HW and preload cache<br /> * on cpu-1. Now later in preload_new_slb_context(), when we will try<br /> * to add the same preload entry again, we will add this to the SW<br /> * preload cache and then will add it to the HW SLB. Since on cpu-0<br /> * this entry was never invalidated, hence adding this entry to the HW<br /> * SLB will cause a SLB multi-hit error.<br /> */<br /> load_elf_binary cont<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> svcrdma: bound check rq_pages index in inline path<br /> <br /> svc_rdma_copy_inline_range indexed rqstp-&gt;rq_pages[rc_curpage] without<br /> verifying rc_curpage stays within the allocated page array. Add guards<br /> before the first use and after advancing to a new page.