CVE-2022-49814

Technical Description

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

kcm: close race conditions on sk_receive_queue

sk->sk_receive_queue is protected by skb queue lock, but for KCM

sockets its RX path takes mux->rx_lock to protect more than just

skb queue. However, kcm_recvmsg() still only grabs the skb queue

lock, so race conditions still exist.

We can teach kcm_recvmsg() to grab mux->rx_lock 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 requeue_rx_msgs() and handle

skb peek case carefully in kcm_wait_data(). Fortunately,

skb_recv_datagram() already handles it nicely and is widely used by

other sockets, we can just switch to skb_recv_datagram() after

getting rid of the unnecessary sock lock in kcm_recvmsg() and

kcm_splice_read(). Side note: SOCK_DONE 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

Remediation

Check the references section for vendor advisories and patches from linux. Update linux_kernel to the latest patched version. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

Affected Products

References