kernel/linux.git, branch v6.6.158

Linux 6.6.158

2026-10-03T10:31:19+00:00

Link: https://lore.kernel.org/r/20260930152434.301151190@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Pavel Machek (CIP) Tested-by: Ron Economos Tested-by: Miguel Ojeda Tested-by: Brett A C Sheffield Tested-by: Barry K. Nathan Tested-by: Wentao Guan Signed-off-by: Greg Kroah-Hartman

net: mediatek: Fix potential NULL pointer dereference in dummy net_device handling

2026-10-03T10:31:19+00:00

commit 16f3a28cf5f876a7f3550d8f4c870a7b41bcfaef upstream. Move the freeing of the dummy net_device from mtk_free_dev() to mtk_remove(). Previously, if alloc_netdev_dummy() failed in mtk_probe(), eth->dummy_dev would be NULL. The error path would then call mtk_free_dev(), which in turn called free_netdev() assuming dummy_dev was allocated (but it was not), potentially causing a NULL pointer dereference. By moving free_netdev() to mtk_remove(), we ensure it's only called when mtk_probe() has succeeded and dummy_dev is fully allocated. This addresses a potential NULL pointer dereference detected by Smatch[1]. Fixes: b209bd6d0bff ("net: mediatek: mtk_eth_sock: allocate dummy net_device dynamically") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/4160f4e0-cbef-4a22-8b5d-42c4d399e1f7@stanley.mountain/ [1] Suggested-by: Dan Carpenter Reviewed-by: Dan Carpenter Signed-off-by: Breno Leitao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20240724080524.2734499-1-leitao@debian.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman

crypto: atmel-ecc - avoid stale fallback key after set_secret failure

2026-10-03T10:31:19+00:00

[ Upstream commit f07a0d251db7606e4792d2610788fbcc7b2c0d12 ] Clear ->do_fallback before decoding a new ECDH secret and enable it only after the software fallback accepts a caller-provided private key. This avoids using a stale fallback key should crypto_kpp_set_secret() fail. Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

netfilter: nf_tables: don't queue packet path object notifications

2026-10-03T10:31:19+00:00

[ Upstream commit 7904b94768e983bcb2be34a8d6d1f3450f5b838b ] All file:line references below are against v7.2-rc4 (ac5b0e5651b1). The trace was captured on 7.2.0-rc6-kasan72rc6 (075b74841bd0), where the same lines apply. nft_obj_notify() is exported and reached from the packet path. Its only in-tree caller is nft_quota_obj_eval() (net/netfilter/nft_quota.c:68), which notifies with GFP_ATOMIC while evaluating a rule for a transiting packet, holding no mutex. Since commit 67cc570edaa0 ("netfilter: nf_tables: coalesce multiple notifications into one skbuff") that notification is no longer sent immediately. __nft_obj_notify() queues it onto nft_net->notify_list via nft_notify_enqueue() (net/netfilter/nf_tables_api.c:1211), which is a bare list_add_tail(). notify_list has no lock of its own (include/net/netfilter/nf_tables.h:1951), it is serialised by commit_mutex: the six other enqueue sites all run inside a netlink transaction, and the drain in nft_commit_notify() (net/netfilter/nf_tables_api.c:10746) does list_del() + kfree_skb() from nf_tables_commit() with commit_mutex held. Sending packets through a chain that references a depleted quota object therefore races an unlocked list_add_tail() against list_del() + kfree_skb() on another CPU. The WRITE_ONCE(prev->next, new) in __list_add() then stores through an sk_buff that has already been freed: BUG: KASAN: slab-use-after-free in __nft_obj_notify+0x2c5/0x2d0 Write of size 8 at addr ff110001047183c0 by task poc/76 CPU: 0 UID: 1000 PID: 76 Comm: poc Tainted: G W 7.2.0-rc6-kasan72rc6 #4 Call Trace: __nft_obj_notify (include/linux/list.h:164 include/linux/list.h:191 net/netfilter/nf_tables_api.c:1211 net/netfilter/nf_tables_api.c:8743) nft_quota_obj_eval (net/netfilter/nft_quota.c:68) nft_do_chain_inet nf_hook_slow __ip_local_out ip_push_pending_frames udp_send_skb udp_sendmsg __x64_sys_sendto Allocated by task 77: __alloc_skb (net/core/skbuff.c:704) __nft_obj_notify (include/net/netlink.h:1055 net/netfilter/nf_tables_api.c:8731) nft_quota_obj_eval (net/netfilter/nft_quota.c:68) nft_do_chain Freed by task 79: nf_tables_commit (include/linux/skbuff.h:1332 net/netfilter/nf_tables_api.c:10759 net/netfilter/nf_tables_api.c:11185) nfnetlink_rcv_batch (net/netfilter/nfnetlink.c:574) netlink_unicast netlink_sendmsg The buggy address belongs to the cache skbuff_head_cache of size 232 Queueing from the packet path is wrong even leaving the race aside: notify_list is only drained by nft_commit_notify() from nf_tables_commit() (:11185), so a notification enqueued outside a transaction is not sent until some later netlink batch commits, if one ever does. The gfp argument that nft_obj_notify() still takes is a leftover of the pre-67cc570edaa0 behaviour, where this path called nfnetlink_send() directly. Restore that: split the message construction out into nft_obj_notify_alloc() and let each caller decide what to do with the skb. nft_obj_notify(), the exported one reached from the packet path, sends it straight away; nf_tables_obj_notify(), which runs under commit_mutex, keeps queueing it, so transaction notifications are still coalesced. Fixes: 67cc570edaa0 ("netfilter: nf_tables: coalesce multiple notifications into one skbuff") Cc: stable@kernel.org Reported-by: TencentOS Corvus AI Assisted-by: tencentos-corvus-ai:kimi-k3 Signed-off-by: Fourie Zhang Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

netfilter: nf_tables: place base_seq in struct net

2026-10-03T10:31:19+00:00

[ Upstream commit 64102d9bbc3d41dac5188b8fba75b1344c438970 ] This will soon be read from packet path around same time as the gencursor. Both gencursor and base_seq get incremented almost at the same time, so it makes sense to place them in the same structure. This doesn't increase struct net size on 64bit due to padding. Signed-off-by: Florian Westphal Stable-dep-of: 7904b94768e9 ("netfilter: nf_tables: don't queue packet path object notifications") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

netfilter: nft_set_rbtree: Remove unused variable nft_net

2026-10-03T10:31:19+00:00

[ Upstream commit 67059b61597c004e23b074547b40604222bee3a0 ] The code that uses nft_net has been removed, and the nft_pernet function is merely obtaining a reference to shared data through the net pointer. The content of the net pointer is not modified or changed, so both of them should be removed. silence the warning: net/netfilter/nft_set_rbtree.c:627:26: warning: variable ‘nft_net’ set but not used Reported-by: Abaci Robot Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7103 Signed-off-by: Yang Li Reviewed-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 7904b94768e9 ("netfilter: nf_tables: don't queue packet path object notifications") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

crypto: virtio - bound the akcipher result length

2026-10-03T10:31:19+00:00

[ Upstream commit f77a956f6a19f9463ef1527c9d0cda50dded6b92 ] virtio_crypto_dataq_akcipher_callback() sets the result length from the device-reported response length without bounding it to the destination buffer, which was allocated for the original request length. sg_copy_from_buffer() then reads that many bytes from the destination buffer; a backend reporting a larger length over-reads adjacent kernel heap into the caller's scatterlist (an out-of-bounds read). Clamp the reported length to the originally requested destination length. A conforming device reports no more than that, so valid results are unaffected. Fixes: a36bd0ad9fbf ("virtio-crypto: adjust dst_len at ops callback") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Message-ID: <20260622-b4-disp-3a2c09a8-v2-1-d1a809281db4@proton.me> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

crypto: virtio - Drop superfluous [as]kcipher_req pointer

2026-10-03T10:31:19+00:00

[ Upstream commit 62d027fb49c76475c5256ab69059752f42c3730f ] The request context virtio_crypto_{akcipher,sym}_request contains a pointer to the [as]kcipher_request itself. The pointer is superfluous as it can be calculated with container_of(). Drop the superfluous pointer. Signed-off-by: Lukas Wunner Signed-off-by: Herbert Xu Stable-dep-of: f77a956f6a19 ("crypto: virtio - bound the akcipher result length") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

crypto: virtio - Drop superfluous [as]kcipher_ctx pointer

2026-10-03T10:31:18+00:00

[ Upstream commit dc91d858fb9251b25828ab63ac7220145cef282c ] The request context virtio_crypto_{akcipher,sym}_request contains a pointer to the transform context virtio_crypto_[as]kcipher_ctx. The pointer is superfluous as it can be calculated with the cheap crypto_akcipher_reqtfm() + akcipher_tfm_ctx() and crypto_skcipher_reqtfm() + crypto_skcipher_ctx() combos. Drop the superfluous pointer. Signed-off-by: Lukas Wunner Signed-off-by: Herbert Xu Stable-dep-of: f77a956f6a19 ("crypto: virtio - bound the akcipher result length") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

crypto: virtio - Drop sign/verify operations

2026-10-03T10:31:18+00:00

[ Upstream commit 5b553e06b3215fa97d222ebddc2bc964f1824c5b ] The virtio crypto driver exposes akcipher sign/verify operations in a user space ABI. This blocks removal of sign/verify from akcipher_alg. Herbert opines: "I would say that this is something that we can break. Breaking it is no different to running virtio on a host that does not support these algorithms. After all, a software implementation must always be present. I deliberately left akcipher out of crypto_user because the API is still in flux. We should not let virtio constrain ourselves." https://lore.kernel.org/all/ZtqoNAgcnXnrYhZZ@gondor.apana.org.au/ "I would remove virtio akcipher support in its entirety. This API was never meant to be exposed outside of the kernel." https://lore.kernel.org/all/Ztqql_gqgZiMW8zz@gondor.apana.org.au/ Drop sign/verify support from virtio crypto. There's no strong reason to also remove encrypt/decrypt support, so keep it. A key selling point of virtio crypto is to allow guest access to crypto accelerators on the host. So far the only akcipher algorithm supported by virtio crypto is RSA. Dropping sign/verify merely means that the PKCS#1 padding is now always generated or verified inside the guest, but the actual signature generation/verification (which is an RSA decrypt/encrypt operation) may still use an accelerator on the host. Generating or verifying the PKCS#1 padding is cheap, so a hardware accelerator won't be of much help there. Which begs the question whether virtio crypto support for sign/verify makes sense at all. It would make sense for the sign operation if the host has a security chip to store asymmetric private keys. But the kernel doesn't even have an asymmetric_key_subtype yet for hardware-based private keys. There's at least one rudimentary driver for such chips (atmel-ecc.c for ATECC508A), but it doesn't implement the sign operation. The kernel would first have to grow support for a hardware asymmetric_key_subtype and at least one driver implementing the sign operation before exposure to guests via virtio makes sense. Signed-off-by: Lukas Wunner Signed-off-by: Herbert Xu Stable-dep-of: f77a956f6a19 ("crypto: virtio - bound the akcipher result length") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman