CVE-2022-49814

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

kcm: close race conditions on skreceivequeue

sk->skreceivequeue is protected by skb queue lock, but for KCM sockets its RX path takes mux->rxlock to protect more than just skb queue. However, kcmrecvmsg() still only grabs the skb queue lock, so race conditions still exist.

We can teach kcmrecvmsg() to grab mux->rxlock too but this would introduce a potential performance regression as struct kcm_mux can be shared by multiple KCM sockets.

So we have to enforce skb queue lock in requeuerxmsgs() and handle skb peek case carefully in kcmwaitdata(). Fortunately, skbrecvdatagram() already handles it nicely and is widely used by other sockets, we can just switch to skbrecvdatagram() after getting rid of the unnecessary sock lock in kcmrecvmsg() and kcmspliceread(). Side note: SOCKDONE is not used by KCM sockets, so it is safe to get rid of this check too.

I ran the original syzbot reproducer for 30 min without seeing any issue.