CVE-2022-50174

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

net: hinic: avoid kernel hung in hinicgetstats64()

When using hinic device as a bond slave device, and reading device stats of master bond device, the kernel may hung.

The kernel panic calltrace as follows: Kernel panic - not syncing: softlockup: hung tasks Call trace: nativequeuedspinlockslowpath+0x1ec/0x31c devgetstats+0x60/0xcc devseqprintfstats+0x40/0x120 devseqshow+0x1c/0x40 seqreaditer+0x3c8/0x4dc seqread+0xe0/0x130 procregread+0xa8/0xe0 vfsread+0xb0/0x1d4 ksysread+0x70/0xfc __arm64sysread+0x20/0x30 el0svccommon+0x88/0x234 doel0svc+0x2c/0x90 el0svc+0x1c/0x30 el0synchandler+0xa8/0xb0 el0sync+0x148/0x180

And the calltrace of task that actually caused kernel hungs as follows: __switch_to+124 __schedule+548 schedule+72 schedule_timeout+348 __down_common+188 __down+24 down+104 hinicgetstats64+44 [hinic] devgetstats+92 bondgetstats+172 [bonding] devgetstats+92 devseqprintfstats+60 devseqshow+24 seqreaditer+964 seqread+220 procregread+164 vfsread+172 ksysread+108 __arm64sysread+28 el0svccommon+132 doel0svc+40 el0svc+24 el0synchandler+164 el0sync+324

When getting device stats from bond, kernel will call bondgetstats(). It first holds the spinlock bond->statslock, and then call hinicgetstats64() to collect hinic device's stats. However, hinicget_stats64() calls down(&nic_dev->mgmt_lock) to protect its critical section, which may schedule current task out. And if system is under high pressure, the task cannot be woken up immediately, which eventually triggers kernel hung panic.

Since previous patch has replaced hinicdev.txstats/rxstats with local variable in hinicget_stats64(), there is nothing need to be protected by lock, so just removing down()/up() is ok.