CVE-2022-50171

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

crypto: hisilicon/sec - don't sleep when in softirq

When kunpeng920 encryption driver is used to deencrypt and decrypt packets during the softirq, it is not allowed to use mutex lock. The kernel will report the following error:

BUG: scheduling while atomic: swapper/57/0/0x00000300 Call trace: dumpbacktrace+0x0/0x1e4 showstack+0x20/0x2c dumpstack+0xd8/0x140 _schedulebug+0x68/0x80 _schedule+0x728/0x840 schedule+0x50/0xe0 schedulepreemptdisabled+0x18/0x24 _mutexlock.constprop.0+0x594/0x5dc _mutexlockslowpath+0x1c/0x30 mutexlock+0x50/0x60 secrequestinit+0x8c/0x1a0 [hisisec2] secprocess+0x28/0x1ac [hisisec2] secskciphercrypto+0xf4/0x1d4 [hisisec2] secskcipherencrypt+0x1c/0x30 [hisisec2] cryptoskcipherencrypt+0x2c/0x40 cryptoauthencencrypt+0xc8/0xfc [authenc] cryptoaeadencrypt+0x2c/0x40 echainivencrypt+0x144/0x1a0 [echainiv] cryptoaeadencrypt+0x2c/0x40 espoutputtail+0x348/0x5c0 [esp4] espoutput+0x120/0x19c [esp4] xfrmoutputone+0x25c/0x4d4 xfrmoutputresume+0x6c/0x1fc xfrmoutput+0xac/0x3c0 xfrm4output+0x64/0x130 ipbuildandsendpkt+0x158/0x20c tcpv4sendsynack+0xdc/0x1f0 tcpconnrequest+0x7d0/0x994 tcpv4connrequest+0x58/0x6c tcpv6connrequest+0xf0/0x100 tcprcvstateprocess+0x1cc/0xd60 tcpv4dorcv+0x10c/0x250 tcpv4rcv+0xfc4/0x10a4 ipprotocoldeliverrcu+0xf4/0x200 iplocaldeliverfinish+0x58/0x70 iplocaldeliver+0x68/0x120 ipsublistrcvfinish+0x70/0x94 iplistrcvfinish.constprop.0+0x17c/0x1d0 ipsublistrcv+0x40/0xb0 iplistrcv+0x140/0x1dc _netifreceiveskblistcore+0x154/0x28c _netifreceiveskblist+0x120/0x1a0 netifreceiveskblistinternal+0xe4/0x1f0 napicompletedone+0x70/0x1f0 grocellpoll+0x9c/0xb0 napipoll+0xcc/0x264 netrxaction+0xd4/0x21c _dosoftirq+0x130/0x358 irqexit+0x11c/0x13c _handledomainirq+0x88/0xf0 gichandleirq+0x78/0x2c0 el1irq+0xb8/0x140 archcpuidle+0x18/0x40 defaultidlecall+0x5c/0x1c0 cpuidleidlecall+0x174/0x1b0 doidle+0xc8/0x160 cpustartupentry+0x30/0x11c secondarystartkernel+0x158/0x1e4 softirq: huh, entered softirq 3 NETRX 0000000093774ee4 with preemptcount 00000100, exited with fffffe00?