In the Linux kernel, the following vulnerability has been resolved:
crypto: pcrypt - Fix hungtask for PADATA_RESET
We found a hungtask bug in testaeadvec_cfg as follows:
INFO: task cryptomgrtest:391009 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. Call trace: _switchto+0x98/0xe0 _schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 scheduletimeout+0x474/0x560 waitforcommon+0x368/0x4e0 waitforcompletion+0x20/0x30 waitforcompletion+0x20/0x30 testaeadveccfg+0xab4/0xd50 testaead+0x144/0x1f0 algtestaead+0xd8/0x1e0 algtest+0x634/0x890 cryptomgrtest+0x40/0x70 kthread+0x1e0/0x220 retfromfork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasks
For padatadoparallel, when the return err is 0 or -EBUSY, it will call waitforcompletion(&wait->completion) in testaeadveccfg. In normal case, aeadrequestcomplete() will be called in pcryptaeadserial and the return err is 0 for padatadoparallel. But, when pinst->flags is PADATARESET, the return err is -EBUSY for padatadoparallel, and it won't call aeadrequestcomplete(). Therefore, testaeadveccfg will hung at waitfor_completion(&wait->completion), which will cause hungtask.
The problem comes as following: (padatadoparallel) | rcureadlockbh(); | err = -EINVAL; | (padatareplace) | pinst->flags |= PADATARESET; err = -EBUSY | if (pinst->flags & PADATARESET) | rcureadunlock_bh() | return err
In order to resolve the problem, we replace the return err -EBUSY with -EAGAIN, which means parallel_data is changing, and the caller should call it again.
v3: remove retry and just change the return err. v2: introduce padatatrydoparallel() in pcryptaeadencrypt and pcryptaead_decrypt to solve the hungtask.