CVE-2025-21727

In the Linux kernel, the following vulnerability has been resolved:

padata: fix UAF in padata_reorder

A bug was found when run ltp test:

BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206

CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0

If mdelay(10) is added before calling padata_find_next in the padata_reorder function, this issue could be reproduced easily with ltp test (pcrypt_aead01).

This can be explained as bellow:

pcrypt_aead_encrypt … padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt … padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on … padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF }

In the padata_reorder function, when it loops in while, if the alg is deleted, the refcnt may be decreased to 0 before entering padata_find_next, which leads to UAF.

As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in padata_free_shell wait for all _do_serial calls to finish.

[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/

Weakness

Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.

Affected Software

Extended Description

The use of previously-freed memory can have any number of adverse consequences, ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system’s reuse of the freed memory. Use-after-free errors have two common and sometimes overlapping causes:

In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process. If the newly allocated data happens to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.

Potential Mitigations

References

• https://git.kernel.org/stable/c/0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd
• https://git.kernel.org/stable/c/573ac9c70bf7885dc85d82fa44550581bfc3b738
• https://git.kernel.org/stable/c/80231f069240d52e98b6a317456c67b2eafd0781
• https://git.kernel.org/stable/c/bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de
• https://git.kernel.org/stable/c/e01780ea4661172734118d2a5f41bc9720765668
• https://git.kernel.org/stable/c/f3e0b9f790f8e8065d59e67b565a83154d9f3079
• https://git.kernel.org/stable/c/f78170bee51469734b1a306a74fc5f777bb22ba6