Skip to main content

Linux CVE-2022-49814

MEDIUM
Race Condition (CWE-362)
2025-05-01 416baaa9-dc9f-4396-8d5f-8c081fb06d67
4.7
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
4.7 MEDIUM
AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
High
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

3
Analysis Generated
Mar 28, 2026 - 18:39 vuln.today
Patch released
Mar 28, 2026 - 18:39 nvd
Patch available
CVE Published
May 01, 2025 - 15:16 nvd
MEDIUM 4.7

DescriptionNVD

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.

AnalysisAI

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. Rated medium severity (CVSS 4.7).

Technical ContextAI

This vulnerability is classified under CWE-362. 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. Affected products include: Linux Linux Kernel.

RemediationAI

A vendor patch is available. Apply the latest security update as soon as possible. Apply vendor patches when available. Implement network segmentation and monitoring as interim mitigations.

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
Image SLES12-SP5-Azure-BYOS Image SLES12-SP5-Azure-HPC-BYOS Image SLES12-SP5-EC2-BYOS Image SLES12-SP5-EC2-ECS-On-Demand Image SLES12-SP5-EC2-On-Demand Image SLES12-SP5-GCE-BYOS Image SLES12-SP5-GCE-On-Demand Affected
Image SLES12-SP5-Azure-SAP-BYOS Image SLES12-SP5-Azure-SAP-On-Demand Image SLES12-SP5-EC2-SAP-BYOS Image SLES12-SP5-EC2-SAP-On-Demand Image SLES12-SP5-GCE-SAP-BYOS Image SLES12-SP5-GCE-SAP-On-Demand Image SLES12-SP5-SAP-Azure-LI-BYOS-Production Image SLES12-SP5-SAP-Azure-VLI-BYOS-Production Affected
SUSE Linux Enterprise Server 12 SP5-LTSS Fixed
SUSE Linux Enterprise Server LTSS Extended Security 12 SP5 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed

Share

CVE-2022-49814 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy