Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 9p/net: fix improper handling of bogus negative read/write replies<br /> <br /> In p9_client_write() and p9_client_read_once(), if the server<br /> incorrectly replies with success but a negative write/read count then we<br /> would consider written (negative) 3)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: work around sched_yield not yielding in time-travel mode<br /> <br /> sched_yield by a userspace may not actually cause scheduling in<br /> time-travel mode as no time has passed. In the case seen it appears to<br /> be a badly implemented userspace spinlock in ASAN. Unfortunately, with<br /> time-travel it causes an extreme slowdown or even deadlock depending on<br /> the kernel configuration (CONFIG_UML_MAX_USERSPACE_ITERATIONS).<br /> <br /> Work around it by accounting time to the process whenever it executes a<br /> sched_yield syscall.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Fix WARN_ON(!ctx) in __free_event() for partial init<br /> <br /> Move the get_ctx(child_ctx) call and the child_event-&gt;ctx assignment to<br /> occur immediately after the child event is allocated. Ensure that<br /> child_event-&gt;ctx is non-NULL before any subsequent error path within<br /> inherit_event calls free_event(), satisfying the assumptions of the<br /> cleanup code.<br /> <br /> Details:<br /> <br /> There&amp;#39;s no clear Fixes tag, because this bug is a side-effect of<br /> multiple interacting commits over time (up to 15 years old), not<br /> a single regression.<br /> <br /> The code initially incremented refcount then assigned context<br /> immediately after the child_event was created. Later, an early<br /> validity check for child_event was added before the<br /> refcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was<br /> added, assuming event-&gt;ctx is valid if the pmu_ctx is valid.<br /> The problem is that the WARN_ON_ONCE() could trigger after the initial<br /> check passed but before child_event-&gt;ctx was assigned, violating its<br /> precondition. The solution is to assign child_event-&gt;ctx right after<br /> its initial validation. This ensures the context exists for any<br /> subsequent checks or cleanup routines, resolving the WARN_ON_ONCE().<br /> <br /> To resolve it, defer the refcount update and child_event-&gt;ctx assignment<br /> directly after child_event-&gt;pmu_ctx is set but before checking if the<br /> parent event is orphaned. The cleanup routine depends on<br /> event-&gt;pmu_ctx being non-NULL before it verifies event-&gt;ctx is<br /> non-NULL. This also maintains the author&amp;#39;s original intent of passing<br /> in child_ctx to find_get_pmu_context before its refcount/assignment.<br /> <br /> [ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix deadlock between rcu_tasks_trace and event_mutex.<br /> <br /> Fix the following deadlock:<br /> CPU A<br /> _free_event()<br /> perf_kprobe_destroy()<br /> mutex_lock(&amp;event_mutex)<br /> perf_trace_event_unreg()<br /> synchronize_rcu_tasks_trace()<br /> <br /> There are several paths where _free_event() grabs event_mutex<br /> and calls sync_rcu_tasks_trace. Above is one such case.<br /> <br /> CPU B<br /> bpf_prog_test_run_syscall()<br /> rcu_read_lock_trace()<br /> bpf_prog_run_pin_on_cpu()<br /> bpf_prog_load()<br /> bpf_tracing_func_proto()<br /> trace_set_clr_event()<br /> mutex_lock(&amp;event_mutex)<br /> <br /> Delegate trace_set_clr_event() to workqueue to avoid<br /> such lock dependency.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: prevent hang on link training fail<br /> <br /> [Why]<br /> When link training fails, the phy clock will be disabled. However, in<br /> enable_streams, it is assumed that link training succeeded and the<br /> mux selects the phy clock, causing a hang when a register write is made.<br /> <br /> [How]<br /> When enable_stream is hit, check if link training failed. If it did, fall<br /> back to the ref clock to avoid a hang and keep the system in a recoverable<br /> state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: decrease sc_count directly if fail to queue dl_recall<br /> <br /> A deadlock warning occurred when invoking nfs4_put_stid following a failed<br /> dl_recall queue operation:<br /> T1 T2<br /> nfs4_laundromat<br /> nfs4_get_client_reaplist<br /> nfs4_anylock_blockers<br /> __break_lease<br /> spin_lock // ctx-&gt;flc_lock<br /> spin_lock // clp-&gt;cl_lock<br /> nfs4_lockowner_has_blockers<br /> locks_owner_has_blockers<br /> spin_lock // flctx-&gt;flc_lock<br /> nfsd_break_deleg_cb<br /> nfsd_break_one_deleg<br /> nfs4_put_stid<br /> refcount_dec_and_lock<br /> spin_lock // clp-&gt;cl_lock<br /> <br /> When a file is opened, an nfs4_delegation is allocated with sc_count<br /> initialized to 1, and the file_lease holds a reference to the delegation.<br /> The file_lease is then associated with the file through kernel_setlease.<br /> <br /> The disassociation is performed in nfsd4_delegreturn via the following<br /> call chain:<br /> nfsd4_delegreturn --&gt; destroy_delegation --&gt; destroy_unhashed_deleg --&gt;<br /> nfs4_unlock_deleg_lease --&gt; kernel_setlease --&gt; generic_delete_lease<br /> The corresponding sc_count reference will be released after this<br /> disassociation.<br /> <br /> Since nfsd_break_one_deleg executes while holding the flc_lock, the<br /> disassociation process becomes blocked when attempting to acquire flc_lock<br /> in generic_delete_lease. This means:<br /> 1) sc_count in nfsd_break_one_deleg will not be decremented to 0;<br /> 2) The nfs4_put_stid called by nfsd_break_one_deleg will not attempt to<br /> acquire cl_lock;<br /> 3) Consequently, no deadlock condition is created.<br /> <br /> Given that sc_count in nfsd_break_one_deleg remains non-zero, we can<br /> safely perform refcount_dec on sc_count directly. This approach<br /> effectively avoids triggering deadlock warnings.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: txgbe: fix memory leak in txgbe_probe() error path<br /> <br /> When txgbe_sw_init() is called, memory is allocated for wx-&gt;rss_key<br /> in wx_init_rss_key(). However, in txgbe_probe() function, the subsequent<br /> error paths after txgbe_sw_init() don&amp;#39;t free the rss_key. Fix that by<br /> freeing it in error path along with wx-&gt;mac_table.<br /> <br /> Also change the label to which execution jumps when txgbe_sw_init()<br /> fails, because otherwise, it could lead to a double free for rss_key,<br /> when the mac_table allocation fails in wx_sw_init().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: bnxt: fix missing ring index trim on error path<br /> <br /> Commit under Fixes converted tx_prod to be free running but missed<br /> masking it on the Tx error path. This crashes on error conditions,<br /> for example when DMA mapping fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ngbe: fix memory leak in ngbe_probe() error path<br /> <br /> When ngbe_sw_init() is called, memory is allocated for wx-&gt;rss_key<br /> in wx_init_rss_key(). However, in ngbe_probe() function, the subsequent<br /> error paths after ngbe_sw_init() don&amp;#39;t free the rss_key. Fix that by<br /> freeing it in error path along with wx-&gt;mac_table.<br /> <br /> Also change the label to which execution jumps when ngbe_sw_init()<br /> fails, because otherwise, it could lead to a double free for rss_key,<br /> when the mac_table allocation fails in wx_sw_init().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: fix PTM cycle trigger logic<br /> <br /> Writing to clear the PTM status &amp;#39;valid&amp;#39; bit while the PTM cycle is<br /> triggered results in unreliable PTM operation. To fix this, clear the<br /> PTM &amp;#39;trigger&amp;#39; and status after each PTM transaction.<br /> <br /> The issue can be reproduced with the following:<br /> <br /> $ sudo phc2sys -R 1000 -O 0 -i tsn0 -m<br /> <br /> Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to<br /> quickly reproduce the issue.<br /> <br /> PHC2SYS exits with:<br /> <br /> "ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction<br /> fails<br /> <br /> This patch also fixes a hang in igc_probe() when loading the igc<br /> driver in the kdump kernel on systems supporting PTM.<br /> <br /> The igc driver running in the base kernel enables PTM trigger in<br /> igc_probe(). Therefore the driver is always in PTM trigger mode,<br /> except in brief periods when manually triggering a PTM cycle.<br /> <br /> When a crash occurs, the NIC is reset while PTM trigger is enabled.<br /> Due to a hardware problem, the NIC is subsequently in a bad busmaster<br /> state and doesn&amp;#39;t handle register reads/writes. When running<br /> igc_probe() in the kdump kernel, the first register access to a NIC<br /> register hangs driver probing and ultimately breaks kdump.<br /> <br /> With this patch, igc has PTM trigger disabled most of the time,<br /> and the trigger is only enabled for very brief (10 - 100 us) periods<br /> when manually triggering a PTM cycle. Chances that a crash occurs<br /> during a PTM trigger are not 0, but extremely reduced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Only create /proc/fs/netfs with CONFIG_PROC_FS<br /> <br /> When testing a special config:<br /> <br /> CONFIG_NETFS_SUPPORTS=y<br /> CONFIG_PROC_FS=n<br /> <br /> The system crashes with something like:<br /> <br /> [ 3.766197] ------------[ cut here ]------------<br /> [ 3.766484] kernel BUG at mm/mempool.c:560!<br /> [ 3.766789] Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> [ 3.767123] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W<br /> [ 3.767777] Tainted: [W]=WARN<br /> [ 3.767968] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> [ 3.768523] RIP: 0010:mempool_alloc_slab.cold+0x17/0x19<br /> [ 3.768847] Code: 50 fe ff 58 5b 5d 41 5c 41 5d 41 5e 41 5f e9 93 95 13 00<br /> [ 3.769977] RSP: 0018:ffffc90000013998 EFLAGS: 00010286<br /> [ 3.770315] RAX: 000000000000002f RBX: ffff888100ba8640 RCX: 0000000000000000<br /> [ 3.770749] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 00000000ffffffff<br /> [ 3.771217] RBP: 0000000000092880 R08: 0000000000000000 R09: ffffc90000013828<br /> [ 3.771664] R10: 0000000000000001 R11: 00000000ffffffea R12: 0000000000092cc0<br /> [ 3.772117] R13: 0000000000000400 R14: ffff8881004b1620 R15: ffffea0004ef7e40<br /> [ 3.772554] FS: 0000000000000000(0000) GS:ffff8881b5f3c000(0000) knlGS:0000000000000000<br /> [ 3.773061] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 3.773443] CR2: ffffffff830901b4 CR3: 0000000004296001 CR4: 0000000000770ef0<br /> [ 3.773884] PKRU: 55555554<br /> [ 3.774058] Call Trace:<br /> [ 3.774232] <br /> [ 3.774371] mempool_alloc_noprof+0x6a/0x190<br /> [ 3.774649] ? _printk+0x57/0x80<br /> [ 3.774862] netfs_alloc_request+0x85/0x2ce<br /> [ 3.775147] netfs_readahead+0x28/0x170<br /> [ 3.775395] read_pages+0x6c/0x350<br /> [ 3.775623] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 3.775928] page_cache_ra_unbounded+0x1bd/0x2a0<br /> [ 3.776247] filemap_get_pages+0x139/0x970<br /> [ 3.776510] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 3.776820] filemap_read+0xf9/0x580<br /> [ 3.777054] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 3.777368] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 3.777674] ? find_held_lock+0x32/0x90<br /> [ 3.777929] ? netfs_start_io_read+0x19/0x70<br /> [ 3.778221] ? netfs_start_io_read+0x19/0x70<br /> [ 3.778489] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 3.778800] ? lock_acquired+0x1e6/0x450<br /> [ 3.779054] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 3.779379] netfs_buffered_read_iter+0x57/0x80<br /> [ 3.779670] __kernel_read+0x158/0x2c0<br /> [ 3.779927] bprm_execve+0x300/0x7a0<br /> [ 3.780185] kernel_execve+0x10c/0x140<br /> [ 3.780423] ? __pfx_kernel_init+0x10/0x10<br /> [ 3.780690] kernel_init+0xd5/0x150<br /> [ 3.780910] ret_from_fork+0x2d/0x50<br /> [ 3.781156] ? __pfx_kernel_init+0x10/0x10<br /> [ 3.781414] ret_from_fork_asm+0x1a/0x30<br /> [ 3.781677] <br /> [ 3.781823] Modules linked in:<br /> [ 3.782065] ---[ end trace 0000000000000000 ]---<br /> <br /> This is caused by the following error path in netfs_init():<br /> <br /> if (!proc_mkdir("fs/netfs", NULL))<br /> goto error_proc;<br /> <br /> Fix this by adding ifdef in netfs_main(), so that /proc/fs/netfs is only<br /> created with CONFIG_PROC_FS.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Clear iommu-dma ops on cleanup<br /> <br /> If iommu_device_register() encounters an error, it can end up tearing<br /> down already-configured groups and default domains, however this<br /> currently still leaves devices hooked up to iommu-dma (and even<br /> historically the behaviour in this area was at best inconsistent across<br /> architectures/drivers...) Although in the case that an IOMMU is present<br /> whose driver has failed to probe, users cannot necessarily expect DMA to<br /> work anyway, it&amp;#39;s still arguable that we should do our best to put<br /> things back as if the IOMMU driver was never there at all, and certainly<br /> the potential for crashing in iommu-dma itself is undesirable. Make sure<br /> we clean up the dev-&gt;dma_iommu flag along with everything else.