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 padatafindnext+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: pdecryptparallel padataparallelworker Call Trace: <TASK> dumpstacklvl+0x32/0x50 printaddressdescription.constprop.0+0x6b/0x3d0 printreport+0xdd/0x2c0 kasanreport+0xa5/0xd0 padatafindnext+0x29/0x1a0 padatareorder+0x131/0x220 padataparallelworker+0x3d/0xc0 processonework+0x2ec/0x5a0

If 'mdelay(10)' is added before calling 'padatafindnext' in the 'padatareorder' function, this issue could be reproduced easily with ltp test (pcryptaead01).

This can be explained as bellow:

pcryptaeadencrypt ... padatadoparallel refcountinc(&pd->refcnt); // add refcnt ... padatadoserial padatareorder // pd while (1) { padatafindnext(pd, true); // using pd queueworkon ... padataserialworker cryptodelalg padataputpdcnt // sub refcnt padatafreeshell padataputpd(ps->pd); // pd is freed // loop again, but pd is freed // call padatafind_next, UAF }

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

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

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