Hello Zach,
On Tue, Dec 03, 2024 at 11:34:26PM +0800, Zach Wade wrote:
> testcases/kernel/crypto/pcrypt_aead01.c of LTP project has UAF.
>
> Steps to reproduce:
> 1. /sys/module/cryptomgr/parameters/notests is N
> 2. run LTP ./testcases/bin/pcrypt_aead01
>
> There is a race condition when padata_free_shell is released, which
> causes it to be accessed after being released. We should use the rcu
> mechanism to protect it.
> cpu0 | cpu1
> ================================================================
> padata_do_parallel | padata_free_shell
> rcu_read_lock_bh | refcount_dec_and_test
> # run to here <- 1 | # run to here <- 2
> refcount_inc(&pd->refcnt); | padata_free_pd <- 3
> padata_work_alloc | ...
> rcu_read_unlock_bh |
I'm not sure this scenario is possible. For padata_free_shell to be
called, I think there can't be any allocated pcrypt aead transforms (so
that the alg refcount is low enough for crypto_del_alg to call
padata_free_shell), but here cpu0 has called padata_do_parallel which
implies it has such a transform.
> There is a possibility of UAF after refcount_inc(&pd->refcnt).
>
> kasan report:
> [158753.658839] ==================================================================
> [158753.658851] BUG: KASAN: slab-use-after-free in padata_find_next+0x2d6/0x3f0
> [158753.658868] Read of size 4 at addr ffff88812f8b8524 by task kworker/u158:0/988818
> [158753.658878]
> [158753.658885] CPU: 23 UID: 0 PID: 988818 Comm: kworker/u158:0 Kdump: loaded Tainted: G W E 6.12.0-dirty #33
> [158753.658902] Tainted: [W]=WARN, [E]=UNSIGNED_MODULE
> [158753.658907] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022
> [158753.658914] Workqueue: pdecrypt_parallel padata_parallel_worker
> [158753.658927] Call Trace:
> [158753.658932] <TASK>
> [158753.658938] dump_stack_lvl+0x5d/0x80
> [158753.658960] print_report+0x174/0x505
> [158753.658992] kasan_report+0xe0/0x160
> [158753.659013] padata_find_next+0x2d6/0x3f0
> [158753.659035] padata_reorder+0x1cc/0x400
> [158753.659043] padata_parallel_worker+0x70/0x160
This report shows the uaf in find_next, not do_parallel. I think this
is the same issue reported recently in this series:
https://lore.kernel.org/all/20241123080509.2573987-1-chenridong@xxxxxxxxxxxxxxx/
