[PATCH net v3] tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done

[PATCH net v3] tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done

[Doruk Tan Ozturk]

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>
---
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..84a6489da036 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(aead->crypto->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(aead->crypto->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

RE: [PATCH net v3] tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done

[Tung Quang Nguyen]

>Subject: [PATCH net v3] tipc: fix slab-use-after-free Read in
>tipc_aead_decrypt_done
>
>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[]
>aead->crypto->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>
>---
>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..84a6489da036 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(aead->crypto->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(aead->crypto->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
>

Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>

Re: [PATCH net v3] tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done

[Simon Horman]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done

This commit attempts to fix a slab-use-after-free read in
tipc_aead_decrypt_done by taking a reference on the network namespace
before starting asynchronous decryption. It mirrors the encrypt-side fix
by keeping the reference across the async return and dropping it when done.

> diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
> index 6d3b6b89b1d17..84a6489da0360 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(aead->crypto->net)) {

[Severity: High]
Could accessing aead->crypto->net read freed memory if the namespace
teardown races with packet decryption?

If aead is a TX cluster key, its crypto pointer points to the per-netns
crypto_tx structure. During a concurrent namespace teardown, tipc_exit_net()
synchronously frees crypto_tx without waiting for an RCU grace period.

Since packet reception (tipc_rcv) executes in softirq under rcu_read_lock()
but without holding a namespace reference, dereferencing aead->crypto to get
the net pointer could result in a use-after-free.

Because tipc_aead_decrypt() already receives the struct net *net directly as
its first parameter, would it be safer to use maybe_get_net(net) instead to
avoid accessing the potentially freed aead->crypto structure entirely?

> +		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(aead->crypto->net);

[Severity: High]
Does this put_net() call have the same use-after-free risk? Could this also
use the net parameter directly instead of dereferencing aead->crypto->net?

[ ... ]