CVE-2022-49814
kcm: close race conditions on sk_receive_queue
We use these services and cookies to improve your user experience. You may opt out if you wish, however, this may limit some features on this site.
Please see our statement on Data Privacy.
kcm: close race conditions on sk_receive_queue
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 without seeing any issue.
Reserved 2025-05-01 | Published 2025-05-01 | Updated 2025-05-04 | Assigner Linuxgit.kernel.org/...c/22f6b5d47396b4287662668ee3f5c1f766cb4259
git.kernel.org/...c/d9ad4de92e184b19bcae4da10dac0275abf83931
git.kernel.org/...c/ce57d6474ae999a3b2d442314087473a646a65c7
git.kernel.org/...c/4154b6afa2bd639214ff259d912faad984f7413a
git.kernel.org/...c/f7b0e95071bb4be4b811af3f0bfc3e200eedeaa3
git.kernel.org/...c/bf92e54597d842da127c59833b365d6faeeaf020
git.kernel.org/...c/5121197ecc5db58c07da95eb1ff82b98b121a221
Support options
