Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vma: fix memory leak in __mmap_region()<br /> <br /> commit 605f6586ecf7 ("mm/vma: do not leak memory when .mmap_prepare<br /> swaps the file") handled the success path by skipping get_file() via<br /> file_doesnt_need_get, but missed the error path.<br /> <br /> When /dev/zero is mmap&amp;#39;d with MAP_SHARED, mmap_zero_prepare() calls<br /> shmem_zero_setup_desc() which allocates a new shmem file to back the<br /> mapping. If __mmap_new_vma() subsequently fails, this replacement<br /> file is never fput()&amp;#39;d - the original is released by<br /> ksys_mmap_pgoff(), but nobody releases the new one.<br /> <br /> Add fput() for the swapped file in the error path.<br /> <br /> Reproducible with fault injection.<br /> <br /> FAULT_INJECTION: forcing a failure.<br /> name failslab, interval 1, probability 0, space 0, times 1<br /> CPU: 2 UID: 0 PID: 366 Comm: syz.7.14 Not tainted 7.0.0-rc6 #2 PREEMPT(full)<br /> Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x164/0x1f0<br /> should_fail_ex+0x525/0x650<br /> should_failslab+0xdf/0x140<br /> kmem_cache_alloc_noprof+0x78/0x630<br /> vm_area_alloc+0x24/0x160<br /> __mmap_region+0xf6b/0x2660<br /> mmap_region+0x2eb/0x3a0<br /> do_mmap+0xc79/0x1240<br /> vm_mmap_pgoff+0x252/0x4c0<br /> ksys_mmap_pgoff+0xf8/0x120<br /> __x64_sys_mmap+0x12a/0x190<br /> do_syscall_64+0xa9/0x580<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> <br /> kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> BUG: memory leak<br /> unreferenced object 0xffff8881118aca80 (size 360):<br /> comm "syz.7.14", pid 366, jiffies 4294913255<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........<br /> ff ff ff ff ff ff ff ff c0 28 4d ae ff ff ff ff .........(M.....<br /> backtrace (crc db0f53bc):<br /> kmem_cache_alloc_noprof+0x3ab/0x630<br /> alloc_empty_file+0x5a/0x1e0<br /> alloc_file_pseudo+0x135/0x220<br /> __shmem_file_setup+0x274/0x420<br /> shmem_zero_setup_desc+0x9c/0x170<br /> mmap_zero_prepare+0x123/0x140<br /> __mmap_region+0xdda/0x2660<br /> mmap_region+0x2eb/0x3a0<br /> do_mmap+0xc79/0x1240<br /> vm_mmap_pgoff+0x252/0x4c0<br /> ksys_mmap_pgoff+0xf8/0x120<br /> __x64_sys_mmap+0x12a/0x190<br /> do_syscall_64+0xa9/0x580<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Found by syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled<br /> <br /> Keep the NOC_HDCP clock always enabled to fix the potential hang<br /> caused by the NoC ADB400 port power down handshake.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Only put the call ref if one was acquired<br /> <br /> rxrpc_input_packet_on_conn() can process a to-client packet after the<br /> current client call on the channel has already been torn down. In that<br /> case chan-&gt;call is NULL, rxrpc_try_get_call() returns NULL and there is<br /> no reference to drop.<br /> <br /> The client-side implicit-end error path does not account for that and<br /> unconditionally calls rxrpc_put_call(). This turns a protocol error<br /> path into a kernel crash instead of rejecting the packet.<br /> <br /> Only drop the call reference if one was actually acquired. Keep the<br /> existing protocol error handling unchanged.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix key reference count leak from call-&gt;key<br /> <br /> When creating a client call in rxrpc_alloc_client_call(), the code obtains<br /> a reference to the key. This is never cleaned up and gets leaked when the<br /> call is destroyed.<br /> <br /> Fix this by freeing call-&gt;key in rxrpc_destroy_call().<br /> <br /> Before the patch, it shows the key reference counter elevated:<br /> <br /> $ cat /proc/keys | grep afs@54321<br /> 1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321: ka<br /> $<br /> <br /> After the patch, the invalidated key is removed when the code exits:<br /> <br /> $ cat /proc/keys | grep afs@54321<br /> $

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix use of wrong skb when comparing queued RESP challenge serial<br /> <br /> In rxrpc_post_response(), the code should be comparing the challenge serial<br /> number from the cached response before deciding to switch to a newer<br /> response, but looks at the newer packet private data instead, rendering the<br /> comparison always false.<br /> <br /> Fix this by switching to look at the older packet.<br /> <br /> Fix further[1] to substitute the new packet in place of the old one if<br /> newer and also to release whichever we don&amp;#39;t use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix RxGK token loading to check bounds<br /> <br /> rxrpc_preparse_xdr_yfs_rxgk() reads the raw key length and ticket length<br /> from the XDR token as u32 values and passes each through round_up(x, 4)<br /> before using the rounded value for validation and allocation. When the raw<br /> length is &gt;= 0xfffffffd, round_up() wraps to 0, so the bounds check and<br /> kzalloc both use 0 while the subsequent memcpy still copies the original<br /> ~4 GiB value, producing a heap buffer overflow reachable from an<br /> unprivileged add_key() call.<br /> <br /> Fix this by:<br /> <br /> (1) Rejecting raw key lengths above AFSTOKEN_GK_KEY_MAX and raw ticket<br /> lengths above AFSTOKEN_GK_TOKEN_MAX before rounding, consistent with<br /> the caps that the RxKAD path already enforces via AFSTOKEN_RK_TIX_MAX.<br /> <br /> (2) Sizing the flexible-array allocation from the validated raw key<br /> length via struct_size_t() instead of the rounded value.<br /> <br /> (3) Caching the raw lengths so that the later field assignments and<br /> memcpy calls do not re-read from the token, eliminating a class of<br /> TOCTOU re-parse.<br /> <br /> The control path (valid token with lengths within bounds) is unaffected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix key parsing memleak<br /> <br /> In rxrpc_preparse_xdr_yfs_rxgk(), the memory attached to token-&gt;rxgk can be<br /> leaked in a few error paths after it&amp;#39;s allocated.<br /> <br /> Fix this by freeing it in the "reject_token:" case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lan966x: fix use-after-free and leak in lan966x_fdma_reload()<br /> <br /> When lan966x_fdma_reload() fails to allocate new RX buffers, the restore<br /> path restarts DMA using old descriptors whose pages were already freed<br /> via lan966x_fdma_rx_free_pages(). Since page_pool_put_full_page() can<br /> release pages back to the buddy allocator, the hardware may DMA into<br /> memory now owned by other kernel subsystems.<br /> <br /> Additionally, on the restore path, the newly created page pool (if<br /> allocation partially succeeded) is overwritten without being destroyed,<br /> leaking it.<br /> <br /> Fix both issues by deferring the release of old pages until after the<br /> new allocation succeeds. Save the old page array before the allocation<br /> so old pages can be freed on the success path. On the failure path, the<br /> old descriptors, pages and page pool are all still valid, making the<br /> restore safe. Also ensure the restore path re-enables NAPI and wakes<br /> the netdev, matching the success path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lan966x: fix page pool leak in error paths<br /> <br /> lan966x_fdma_rx_alloc() creates a page pool but does not destroy it if<br /> the subsequent fdma_alloc_coherent() call fails, leaking the pool.<br /> <br /> Similarly, lan966x_fdma_init() frees the coherent DMA memory when<br /> lan966x_fdma_tx_alloc() fails but does not destroy the page pool that<br /> was successfully created by lan966x_fdma_rx_alloc(), leaking it.<br /> <br /> Add the missing page_pool_destroy() calls in both error paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lan966x: fix page_pool error handling in lan966x_fdma_rx_alloc_page_pool()<br /> <br /> page_pool_create() can return an ERR_PTR on failure. The return value<br /> is used unconditionally in the loop that follows, passing the error<br /> pointer through xdp_rxq_info_reg_mem_model() into page_pool_use_xdp_mem(),<br /> which dereferences it, causing a kernel oops.<br /> <br /> Add an IS_ERR check after page_pool_create() to return early on failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: reject undecryptable rxkad response tickets<br /> <br /> rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then<br /> parses the buffer as plaintext without checking whether<br /> crypto_skcipher_decrypt() succeeded.<br /> <br /> A malformed RESPONSE can therefore use a non-block-aligned ticket<br /> length, make the decrypt operation fail, and still drive the ticket<br /> parser with attacker-controlled bytes.<br /> <br /> Check the decrypt result and abort the connection with RXKADBADTICKET<br /> when ticket decryption fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix call removal to use RCU safe deletion<br /> <br /> Fix rxrpc call removal from the rxnet-&gt;calls list to use list_del_rcu()<br /> rather than list_del_init() to prevent stuffing up reading<br /> /proc/net/rxrpc/calls from potentially getting into an infinite loop.<br /> <br /> This, however, means that list_empty() no longer works on an entry that&amp;#39;s<br /> been deleted from the list, making it harder to detect prior deletion. Fix<br /> this by:<br /> <br /> Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that<br /> are unexpectedly still on the list. Limiting the number of steps means<br /> there&amp;#39;s no need to call cond_resched() or to remove calls from the list<br /> here, thereby eliminating the need for rxrpc_put_call() to check for that.<br /> <br /> rxrpc_put_call() can then be fixed to unconditionally delete the call from<br /> the list as it is the only place that the deletion occurs.