Vulnerabilities

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 /> idpf: fix PREEMPT_RT raw/bh spinlock nesting for async VC handling<br /> <br /> Switch from using the completion&amp;#39;s raw spinlock to a local lock in the<br /> idpf_vc_xn struct. The conversion is safe because complete/_all() are<br /> called outside the lock and there is no reason to share the completion<br /> lock in the current logic. This avoids invalid wait context reported by<br /> the kernel due to the async handler taking BH spinlock:<br /> <br /> [ 805.726977] =============================<br /> [ 805.726991] [ BUG: Invalid wait context ]<br /> [ 805.727006] 7.0.0-rc2-net-devq-031026+ #28 Tainted: G S OE<br /> [ 805.727026] -----------------------------<br /> [ 805.727038] kworker/u261:0/572 is trying to lock:<br /> [ 805.727051] ff190da6a8dbb6a0 (&amp;vport_config-&gt;mac_filter_list_lock){+...}-{3:3}, at: idpf_mac_filter_async_handler+0xe9/0x260 [idpf]<br /> [ 805.727099] other info that might help us debug this:<br /> [ 805.727111] context-{5:5}<br /> [ 805.727119] 3 locks held by kworker/u261:0/572:<br /> [ 805.727132] #0: ff190da6db3e6148 ((wq_completion)idpf-0000:83:00.0-mbx){+.+.}-{0:0}, at: process_one_work+0x4b5/0x730<br /> [ 805.727163] #1: ff3c6f0a6131fe50 ((work_completion)(&amp;(&amp;adapter-&gt;mbx_task)-&gt;work)){+.+.}-{0:0}, at: process_one_work+0x1e5/0x730<br /> [ 805.727191] #2: ff190da765190020 (&amp;x-&gt;wait#34){+.+.}-{2:2}, at: idpf_recv_mb_msg+0xc8/0x710 [idpf]<br /> [ 805.727218] stack backtrace:<br /> ...<br /> [ 805.727238] Workqueue: idpf-0000:83:00.0-mbx idpf_mbx_task [idpf]<br /> [ 805.727247] Call Trace:<br /> [ 805.727249] <br /> [ 805.727251] dump_stack_lvl+0x77/0xb0<br /> [ 805.727259] __lock_acquire+0xb3b/0x2290<br /> [ 805.727268] ? __irq_work_queue_local+0x59/0x130<br /> [ 805.727275] lock_acquire+0xc6/0x2f0<br /> [ 805.727277] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf]<br /> [ 805.727284] ? _printk+0x5b/0x80<br /> [ 805.727290] _raw_spin_lock_bh+0x38/0x50<br /> [ 805.727298] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf]<br /> [ 805.727303] idpf_mac_filter_async_handler+0xe9/0x260 [idpf]<br /> [ 805.727310] idpf_recv_mb_msg+0x1c8/0x710 [idpf]<br /> [ 805.727317] process_one_work+0x226/0x730<br /> [ 805.727322] worker_thread+0x19e/0x340<br /> [ 805.727325] ? __pfx_worker_thread+0x10/0x10<br /> [ 805.727328] kthread+0xf4/0x130<br /> [ 805.727333] ? __pfx_kthread+0x10/0x10<br /> [ 805.727336] ret_from_fork+0x32c/0x410<br /> [ 805.727345] ? __pfx_kthread+0x10/0x10<br /> [ 805.727347] ret_from_fork_asm+0x1a/0x30<br /> [ 805.727354]

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 /> 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 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 /> 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 /> 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.

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 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 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: 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: 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.