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:
- /sys/module/cryptomgr/parameters/notests is N
- 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@huaweicloud....