CVE-2021-47041

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

nvmet-tcp: fix incorrect locking in state_change sk callback

We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock.

This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests:

================================ WARNING: inconsistent lock state

5.12.0-rc3 #1 Tainted: G I

inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AFINET){++-?}-{2:2}, at: nvmetcpstatechange+0x21/0x150 [nvmetcp] {IN-SOFTIRQ-W} state was registered at: _lockacquire+0x79b/0x18d0 lockacquire+0x1ca/0x480 rawwritelockbh+0x39/0x80 nvmettcpstatechange+0x21/0x170 [nvmettcp] tcpfin+0x2a8/0x780 tcpdataqueue+0xf94/0x1f20 tcprcvestablished+0x6ba/0x1f00 tcpv4dorcv+0x502/0x760 tcpv4rcv+0x257e/0x3430 ipprotocoldeliverrcu+0x69/0x6a0 iplocaldeliverfinish+0x1e2/0x2f0 iplocaldeliver+0x1a2/0x420 iprcv+0x4fb/0x6b0 _netifreceiveskbonecore+0x162/0x1b0 processbacklog+0x1ff/0x770 _napipoll.constprop.0+0xa9/0x5c0 netrxaction+0x7b3/0xb30 _dosoftirq+0x1f0/0x940 dosoftirq+0xa1/0xd0 _localbhenableip+0xd8/0x100 ipfinishoutput2+0x6b7/0x18a0 _ipqueuexmit+0x706/0x1aa0 _tcptransmitskb+0x2068/0x2e20 tcpwritexmit+0xc9e/0x2bb0 _tcppushpendingframes+0x92/0x310 inetshutdown+0x158/0x300 _nvmetcpstopqueue+0x36/0x270 [nvmetcp] nvmetcpstopqueue+0x87/0xb0 [nvmetcp] nvmetcpteardownadminqueue+0x69/0xe0 [nvmetcp] nvmedodeletectrl+0x100/0x10c [nvmecore] nvmesysfsdelete.cold+0x8/0xd [nvmecore] kernfsfopwriteiter+0x2c7/0x460 newsyncwrite+0x36c/0x610 vfswrite+0x5c0/0x870 ksyswrite+0xf9/0x1d0 dosyscall64+0x33/0x40 entrySYSCALL64afterhwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687): [<ffffffff9ec376bd>] _rawspinunlockirqrestore+0x2d/0x40 hardirqs last disabled at (10686): [<ffffffff9ec374d8>] rawspinlockirqsave+0x68/0x90 softirqs last enabled at (10684): [<ffffffff9f000608>] _dosoftirq+0x608/0x940 softirqs last disabled at (10649): [<ffffffff9cdedd31>] do_softirq+0xa1/0xd0

other info that might help us debug this: Possible unsafe locking scenario:

   CPU0
   ----

lock(clock-AFINET); <Interrupt> lock(clock-AFINET);

* DEADLOCK *

5 locks held by nvme/1324: #0: ffff8884a01fe470 (sbwriters#4){.+.+}-{0:0}, at: ksyswrite+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfsfopwriteiter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfsremoveself+0x22d/0x330 #3: ffff8884634538d0 (&queue->queuelock){+.+.}-{3:3}, at: nvmetcpstopqueue+0x52/0xb0 [nvmetcp] #4: ffff888363150d30 (sklock-AFINET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300

stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dumpstack+0x93/0xc2 marklockirq.cold+0x2c/0xb3 ? verifylockunused+0x390/0x390 ? stacktraceconsumeentry+0x160/0x160 ? lockdowngrade+0x100/0x100 ? savetrace+0x88/0x5e0 ? rawspinunlockirqrestore+0x2d/0x40 marklock+0x530/0x1470 ? marklockirq+0x1d10/0x1d10 ? enqueuetimer+0x660/0x660 markusage+0x215/0x2a0 _lockacquire+0x79b/0x18d0 ? tcpschedulelossprobe.part.0+0x38c/0x520 lockacquire+0x1ca/0x480 ? nvmetcpstatechange+0x21/0x150 [nvmetcp] ? rcureadunlock+0x40/0x40 ? tcpmtuprobe+0x1ae0/0x1ae0 ? kmallocreserve+0xa0/0xa0 ? sysfsfileops+0x170/0x170 rawreadlock+0x3d/0xa0 ? nvmetcpstatechange+0x21/0x150 [nvmetcp] nvmetcpstatechange+0x21/0x150 [nvmetcp] ? sysfsfile_ops ---truncated---