* [PATCH net v4] tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done
@ 2026-06-17 7:58 Doruk Tan Ozturk
2026-06-18 12:56 ` Simon Horman
0 siblings, 1 reply; 2+ messages in thread
From: Doruk Tan Ozturk @ 2026-06-17 7:58 UTC (permalink / raw)
To: jmaloy
Cc: davem, edumazet, kuba, pabeni, horms, aleksander.lobakin,
tung.quang.nguyen, tipc-discussion, netdev, linux-kernel,
Doruk Tan Ozturk, stable
tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to
crypto_aead_decrypt(req) without taking a reference on the netns, unlike
the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously
(e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs
tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the
meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the
per-netns tipc_crypto, and the completion then reads it:
tipc_aead_decrypt_done() dereferences aead->crypto->stats and
aead->crypto->net, and tipc_crypto_rcv_complete() dereferences
aead->crypto->aead[] and the node table -- reading freed memory.
Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO):
BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999)
Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51
Workqueue: events_unbound
Call Trace:
tipc_aead_decrypt_done (net/tipc/crypto.c:999)
process_one_work (kernel/workqueue.c:3314)
worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
Allocated by task 169:
__kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415)
tipc_crypto_start (net/tipc/crypto.c:1502)
tipc_init_net (net/tipc/core.c:72)
ops_init (net/core/net_namespace.c:137)
setup_net (net/core/net_namespace.c:446)
copy_net_ns (net/core/net_namespace.c:579)
create_new_namespaces (kernel/nsproxy.c:132)
__x64_sys_unshare (kernel/fork.c:3316)
do_syscall_64 (arch/x86/entry/syscall_64.c:63)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Freed by task 8:
kfree (mm/slub.c:6566)
tipc_exit_net (net/tipc/core.c:119)
cleanup_net (net/core/net_namespace.c:704)
process_one_work (kernel/workqueue.c:3314)
kthread (kernel/kthread.c:436)
This is the same class of bug that commit e279024617134 ("net/tipc: fix
slab-use-after-free Read in tipc_aead_encrypt_done") fixed for the encrypt
side. The encrypt path takes maybe_get_net(aead->crypto->net) before
crypto_aead_encrypt() and drops it with put_net() on the synchronous
return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY
return keeps the reference for the async callback to release. The decrypt
path was left without the equivalent guard.
Mirror the encrypt-side fix on the decrypt path: take a net reference
before crypto_aead_decrypt() (failing with -ENODEV and the matching
bearer put if it cannot be acquired), keep it across the
-EINPROGRESS/-EBUSY async return, and drop it with put_net() on the
synchronous success/error return and at the end of
tipc_aead_decrypt_done().
Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is
flooded with crafted encrypted frames from an unknown peer (driving the
cluster-key decrypt path) while the bearer's netns is repeatedly torn
down. The completion must run asynchronously to outlive
tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts
synchronously, so the async path was exercised via cryptd offload. The
unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the
unpatched upstream path; tipc_aead_decrypt() still lacks
maybe_get_net(aead->crypto->net), so the completion can outlive the free
on any config where crypto_aead_decrypt() goes async.
Found by 0sec automated security-research tooling (https://0sec.ai).
Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
Cc: stable@vger.kernel.org
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>
---
v4:
- Use the net parameter for maybe_get_net()/put_net() instead of
dereferencing aead->crypto->net, which is the per-netns structure at
risk during teardown (per the automated review forwarded by Simon
Horman). net == aead->crypto->net here; no functional change.
v3:
- Rewrite the changelog with the decoded stack trace and frame the
reproduction on the current tree (v7.1-rc7); drop the v6.12.92
references (Tung Quang Nguyen).
v2:
- Add Cc: stable@vger.kernel.org and Alexander Lobakin's Reviewed-by.
No functional change.
net/tipc/crypto.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
index 6d3b6b89b1d1..16f1ed1f6b1b 100644
--- a/net/tipc/crypto.c
+++ b/net/tipc/crypto.c
@@ -941,12 +941,20 @@ static int tipc_aead_decrypt(struct net *net, struct tipc_aead *aead,
goto exit;
}
+ /* Get net to avoid freed tipc_crypto when delete namespace */
+ if (!maybe_get_net(net)) {
+ tipc_bearer_put(b);
+ rc = -ENODEV;
+ goto exit;
+ }
+
/* Now, do decrypt */
rc = crypto_aead_decrypt(req);
if (rc == -EINPROGRESS || rc == -EBUSY)
return rc;
tipc_bearer_put(b);
+ put_net(net);
exit:
kfree(ctx);
@@ -984,6 +992,7 @@ static void tipc_aead_decrypt_done(void *data, int err)
}
tipc_bearer_put(b);
+ put_net(net);
}
static inline int tipc_ehdr_size(struct tipc_ehdr *ehdr)
--
2.43.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH net v4] tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done
2026-06-17 7:58 [PATCH net v4] tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done Doruk Tan Ozturk
@ 2026-06-18 12:56 ` Simon Horman
0 siblings, 0 replies; 2+ messages in thread
From: Simon Horman @ 2026-06-18 12:56 UTC (permalink / raw)
To: Doruk Tan Ozturk
Cc: jmaloy, davem, edumazet, kuba, pabeni, aleksander.lobakin,
tung.quang.nguyen, tipc-discussion, netdev, linux-kernel, stable
On Wed, Jun 17, 2026 at 09:58:18AM +0200, Doruk Tan Ozturk wrote:
> tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to
> crypto_aead_decrypt(req) without taking a reference on the netns, unlike
> the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously
> (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs
> tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the
> meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the
> per-netns tipc_crypto, and the completion then reads it:
> tipc_aead_decrypt_done() dereferences aead->crypto->stats and
> aead->crypto->net, and tipc_crypto_rcv_complete() dereferences
> aead->crypto->aead[] and the node table -- reading freed memory.
>
> Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO):
>
> BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999)
> Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51
> Workqueue: events_unbound
> Call Trace:
> tipc_aead_decrypt_done (net/tipc/crypto.c:999)
> process_one_work (kernel/workqueue.c:3314)
> worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)
> kthread (kernel/kthread.c:436)
> ret_from_fork (arch/x86/kernel/process.c:158)
> ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
>
> Allocated by task 169:
> __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415)
> tipc_crypto_start (net/tipc/crypto.c:1502)
> tipc_init_net (net/tipc/core.c:72)
> ops_init (net/core/net_namespace.c:137)
> setup_net (net/core/net_namespace.c:446)
> copy_net_ns (net/core/net_namespace.c:579)
> create_new_namespaces (kernel/nsproxy.c:132)
> __x64_sys_unshare (kernel/fork.c:3316)
> do_syscall_64 (arch/x86/entry/syscall_64.c:63)
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
>
> Freed by task 8:
> kfree (mm/slub.c:6566)
> tipc_exit_net (net/tipc/core.c:119)
> cleanup_net (net/core/net_namespace.c:704)
> process_one_work (kernel/workqueue.c:3314)
> kthread (kernel/kthread.c:436)
>
> This is the same class of bug that commit e279024617134 ("net/tipc: fix
> slab-use-after-free Read in tipc_aead_encrypt_done") fixed for the encrypt
> side. The encrypt path takes maybe_get_net(aead->crypto->net) before
> crypto_aead_encrypt() and drops it with put_net() on the synchronous
> return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY
> return keeps the reference for the async callback to release. The decrypt
> path was left without the equivalent guard.
>
> Mirror the encrypt-side fix on the decrypt path: take a net reference
> before crypto_aead_decrypt() (failing with -ENODEV and the matching
> bearer put if it cannot be acquired), keep it across the
> -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the
> synchronous success/error return and at the end of
> tipc_aead_decrypt_done().
>
> Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is
> flooded with crafted encrypted frames from an unknown peer (driving the
> cluster-key decrypt path) while the bearer's netns is repeatedly torn
> down. The completion must run asynchronously to outlive
> tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts
> synchronously, so the async path was exercised via cryptd offload. The
> unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the
> unpatched upstream path; tipc_aead_decrypt() still lacks
> maybe_get_net(aead->crypto->net), so the completion can outlive the free
> on any config where crypto_aead_decrypt() goes async.
>
> Found by 0sec automated security-research tooling (https://0sec.ai).
>
> Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
> Cc: stable@vger.kernel.org
> Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>
> ---
> v4:
> - Use the net parameter for maybe_get_net()/put_net() instead of
> dereferencing aead->crypto->net, which is the per-netns structure at
> risk during teardown (per the automated review forwarded by Simon
> Horman). net == aead->crypto->net here; no functional change.
Thanks for the update.
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-06-18 12:56 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-17 7:58 [PATCH net v4] tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done Doruk Tan Ozturk
2026-06-18 12:56 ` Simon Horman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.