Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: challenge ACK for non-exact RST in SYN-RECEIVED<br /> <br /> The SYN-RECEIVED request-socket path in tcp_check_req() accepts an<br /> in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A<br /> non-exact RST therefore removes the request instead of eliciting a<br /> challenge ACK.<br /> <br /> RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in<br /> SYN-RECEIVED: an exact RST resets the connection, while a non-exact<br /> in-window RST must trigger a challenge ACK and be dropped.<br /> <br /> Apply that check before the ACK-field validation, following the RFC<br /> sequence-number, RST, then ACK processing order. Factor the per-netns<br /> challenge ACK quota out of tcp_send_challenge_ack() so request sockets<br /> can share it. Use the request socket&amp;#39;s send_ack() callback and its own<br /> out-of-window ACK timestamp to send and rate-limit the response.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: initialize standalone TCP-AO response padding<br /> <br /> tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP<br /> responses with TCP-AO options. The option length carries the actual MAC<br /> length, but the TCP header length includes the option rounded up to a<br /> four-byte boundary.<br /> <br /> tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not<br /> four-byte aligned, the one to three bytes after the MAC are left<br /> uninitialized and may be transmitted. For the normal TCP-AO hashing<br /> mode, those bytes also have to be initialized before computing the MAC.<br /> <br /> Initialize only the alignment padding in the TCP-AO branches, before<br /> hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path.<br /> This avoids adding work to non-AO TCP responses while preserving a valid<br /> authenticated header.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()<br /> <br /> There&amp;#39;s no need to crash the kernel for these cases.<br /> <br /> (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON()<br /> <br /> There&amp;#39;s no need to crash the kernel for these cases.<br /> <br /> (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON()<br /> <br /> There&amp;#39;s no need to crash the kernel for these cases.<br /> <br /> (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()<br /> <br /> There&amp;#39;s no need to crash the kernel for these cases.<br /> <br /> (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: clear sock-&gt;sk on the failed-insert path in tipc_sk_create()<br /> <br /> When tipc_sk_create() fails to insert the new socket (tipc_sk_insert()<br /> returns non-zero), its error path frees the sk with sk_free() but leaves<br /> sock-&gt;sk pointing at the freed object:<br /> <br /> if (tipc_sk_insert(tsk)) {<br /> sk_free(sk);<br /> pr_warn("Socket create failed; port number exhausted\n");<br /> return -EINVAL;<br /> }<br /> <br /> This is harmless for plain socket(): the syscall layer clears sock-&gt;ops<br /> before releasing, so tipc_release() is never called. It is not harmless<br /> on the accept() path. tipc_accept() creates the pre-allocated child<br /> socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves<br /> new_sock-&gt;sk dangling and new_sock-&gt;ops non-NULL, and do_accept() then<br /> fput()s the new file, so __sock_release() -&gt; tipc_release() runs<br /> lock_sock(new_sock-&gt;sk) on the freed sk -- a use-after-free write of the<br /> sk_lock spinlock.<br /> <br /> tipc_release() already guards this exact "failed accept() releases a<br /> pre-allocated child" case with "if (sk == NULL) return 0;", but the<br /> guard is bypassed because tipc_sk_create() left sock-&gt;sk non-NULL<br /> (dangling) rather than NULL.<br /> <br /> Clear sock-&gt;sk on the failed-insert path so the existing tipc_release()<br /> NULL check fires and the use-after-free is avoided.<br /> <br /> The tipc_sk_insert() failure is reached when the per-netns socket<br /> rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M<br /> elements) -- i.e. once a netns holds ~2M TIPC sockets every insert<br /> returns -E2BIG.<br /> <br /> BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839)<br /> Write of size 8 at addr ffff8880047cdc38 by task init/1<br /> lock_sock_nested (net/core/sock.c:3839)<br /> tipc_release (net/tipc/socket.c:638)<br /> __sock_release (net/socket.c:710)<br /> sock_close (net/socket.c:1501)<br /> __fput (fs/file_table.c:512)<br /> Allocated by task 1:<br /> sk_alloc (net/core/sock.c:2308)<br /> tipc_sk_create (net/tipc/socket.c:487)<br /> tipc_accept (net/tipc/socket.c:2744)<br /> do_accept (net/socket.c:2034)<br /> Freed by task 1:<br /> __sk_destruct (net/core/sock.c:2391)<br /> tipc_sk_create (net/tipc/socket.c:504)<br /> tipc_accept (net/tipc/socket.c:2744)<br /> do_accept (net/socket.c:2034)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix kernel panic during driver load failure<br /> <br /> Avoid kernel panic if MES init fails during driver load. The KIQ ring is<br /> falsely marked as ready as ASICs that use MES, KIQ is owned by MES.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu]<br /> Call Trace:<br /> gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu]<br /> amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu]<br /> amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu]<br /> amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu]<br /> amdgpu_gart_unbind+0x72/0x90 [amdgpu]<br /> amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu]<br /> amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu]<br /> amdttm_tt_unpopulate+0x29/0x70 [amdttm]<br /> ttm_bo_put+0x1eb/0x360 [amdttm]<br /> amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu]<br /> amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu]<br /> amdgpu_irq_fini_hw+0x58/0x80 [amdgpu]<br /> amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu]<br /> amdgpu_driver_load_kms+0x60/0xa0 [amdgpu]<br /> amdgpu_pci_probe+0x28e/0x6d0 [amdgpu]<br /> pci_device_probe+0x19f/0x220<br /> really_probe+0x1ed/0x340<br /> driver_probe_device+0x1e/0x80<br /> __driver_attach+0xd3/0x1a0<br /> bus_for_each_dev+0x68/0xa0<br /> bus_add_driver+0x19f/0x270<br /> driver_register+0x5d/0xf0<br /> do_one_initcall+0xac/0x200<br /> do_init_module+0x1ec/0x280<br /> __se_sys_finit_module+0x2de/0x310<br /> do_syscall_64+0x6a/0x250<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/vcn4: avoid rereading IB param length<br /> <br /> Reuse the parameter length returned by<br /> vcn_v4_0_enc_find_ib_param() instead of rereading it from<br /> the IB.<br /> <br /> This avoids a potential TOCTOU issue if the IB contents<br /> change between reads.<br /> <br /> (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON()<br /> <br /> There&amp;#39;s no need to crash the kernel for these cases.<br /> <br /> (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()<br /> <br /> There&amp;#39;s no need to crash the kernel for these cases.<br /> <br /> (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: invoke pm_genpd_remove() before freeing genpd<br /> <br /> Call pm_genpd_remove() to unregister from global list prior to releasing<br /> acp_genpd memory, and clear the pointer after free.<br /> <br /> (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)