CVE-2022-49814

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.

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.

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.

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.

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.

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.

The Linux Kernel, the operating system core itself.

Security Fix(es):

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.(CVE-2022-49814)

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

ipvs: fix WARNING in ip_vs_app_net_cleanup()

During the initialization of ip_vs_app_net_init(), if file ip_vs_app fails to be created, the initialization is successful by default. Therefore, the ip_vs_app file doesn't be found during the remove in ip_vs_app_net_cleanup(). It will cause WRNING.

The following is the stack information: name 'ip_vs_app' WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460 Modules linked in: Workqueue: netns cleanup_net RIP: 0010:remove_proc_entry+0x389/0x460 Call Trace: <TASK> ops_exit_list+0x125/0x170 cleanup_net+0x4ea/0xb00 process_one_work+0x9bf/0x1710 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30 </TASK>(CVE-2022-49917)

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

HID: hidraw: fix memory leak in hidraw_release()

Free the buffered reports before deleting the list entry.

BUG: memory leak unreferenced object 0xffff88810e72f180 (size 32): comm "softirq", pid 0, jiffies 4294945143 (age 16.080s) hex dump (first 32 bytes): 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814ac6c3>] kmemdup+0x23/0x50 mm/util.c:128 [<ffffffff8357c1d2>] kmemdup include/linux/fortify-string.h:440 [inline] [<ffffffff8357c1d2>] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521 [<ffffffff8356ddad>] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992 [<ffffffff8356e41e>] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065 [<ffffffff835f0d3f>] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284 [<ffffffff82d3c7f9>] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670 [<ffffffff82d3cc26>] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747 [<ffffffff82ef1e14>] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988 [<ffffffff812f50a8>] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474 [<ffffffff812f5586>] expire_timers kernel/time/timer.c:1519 [inline] [<ffffffff812f5586>] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790 [<ffffffff812f56e4>] __run_timers kernel/time/timer.c:1768 [inline] [<ffffffff812f56e4>] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803 [<ffffffff848000e6>] __do_softirq+0xe6/0x2ea kernel/softirq.c:571 [<ffffffff81246db0>] invoke_softirq kernel/softirq.c:445 [inline] [<ffffffff81246db0>] __irq_exit_rcu kernel/softirq.c:650 [inline] [<ffffffff81246db0>] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662 [<ffffffff84574f02>] sysvec_apic_timer_interrupt+0xa2/0xd0…

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.

The SUSE Linux Enterprise 12 SP5 kernel was updated to receive various security bugfixes.

The following security bugs were fixed:

• CVE-2021-47212: net/mlx5: Update error handler for UCTX and UMEM (bsc#1222709).
• CVE-2021-47455: ptp: Fix possible memory leak in ptp_clock_register() (bsc#1225254).
• CVE-2021-47527: serial: core: fix transmit-buffer reset and memleak (bsc#1227768).
• CVE-2022-21546: scsi: target: Fix WRITE_SAME No Data Buffer crash (bsc#1242243).
• CVE-2022-49154: KVM: SVM: fix panic on out-of-bounds guest IRQ (bsc#1238167).
• CVE-2022-49622: netfilter: nf_tables: fix crash when nf_trace is enabled (bsc#1239042).
• CVE-2022-49731: ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() (bsc#1239071).
• CVE-2022-49764: kABI: workaround 'bpf: Prevent bpf program recursion for raw tracepoint probes' changes (bsc#1242301).
• CVE-2022-49780: scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus() (bsc#1242262).
• CVE-2022-49814: kcm: close race conditions on sk_receive_queue (bsc#1242498).
• CVE-2022-49879: ext4: fix BUG_ON() when directory entry has invalid rec_len (bsc#1242733).
• CVE-2022-49881: wifi: cfg80211: fix memory leak in query_regdb_file() (bsc#1242481).
• CVE-2022-49917: ipvs: fix WARNING in ip_vs_app_net_cleanup() (bsc#1242406).
• CVE-2022-49921: net: sched: Fix use after free in red_enqueue() (bsc#1242359).
• CVE-2022-50055: iavf: Fix adminq error handling (bsc#1245039).
• CVE-2022-50087: firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails (bsc#1245119).
• CVE-2022-50134: RDMA/hfi1: fix potential memory leak in setup_base_ctxt() (bsc#1244802).
• CVE-2022-50200: selinux: Add boundary check in put_entry() (bsc#1245149).
• CVE-2023-52500: Fixed information leaking when processing OPC_INB_SET_CONTROLLER_CONFIG command (bsc#1220883).
• CVE-2023-52927: netfilter: allow exp not to be removed in nf_ct_find_expectation (bsc#1239644).
• CVE-2023-53020: l2tp: fix lockdep splat (bsc#1240224).
• CVE-2023-53090: drm/amdkfd: Fix an illegal memory access (bsc#1242753).
• CVE-2023-53091: ext4: update s_journal_inum if it changes after journal replay (bsc#1242767).
• CVE-2023-53133: bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser() (bsc#1242423).
• CVE-2024-26586: mlxsw: spectrum_acl_tcam: Fix stack corruption (bsc#1220243).
• CVE-2024-26825: nfc: nci: free rx_data_reassembly skb on NCI device cleanup (bsc#1223065).
• CVE-2024-26872: RDMA/srpt: Do not register event handler until srpt device is fully setup (bsc#1223115).
• CVE-2024-26875: media: pvrusb2: fix uaf in pvr2_context_set_notify (bsc#1223118).
• CVE-2024-35790: usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group (bsc#1224712).
• CVE-2024-35839: kABI fix for netfilter: bridge: replace physindev with physinif in nf_bridge_info (bsc#1224726).
• CVE-2024-38588: ftrace: Fix possible use-after-free issue in ftrace_location() (bsc#1226837).
• CVE-2024-57982: xfrm: state: fix out-of-bounds read during lookup (bsc#1237913).
• CVE-2025-21898: ftrace: Avoid potential division by zero in function_stat_show() (bsc#1240610).
• CVE-2025-21920: vlan: enforce underlying device type (bsc#1240686).
• CVE-2025-21971: net_sched: Prevent creation of classes with TC_H_ROOT (bsc#1240799).
• CVE-2025-22035: tracing: Fix use-after-free in print_graph_function_flags during tracer switching (bsc#1241544).
• CVE-2025-23149: tpm: do not start chip while suspended (bsc#1242758).
• CVE-2025-37756: net: tls: explicitly disallow disconnect (bsc#1242515).
• CVE-2025-37757: tipc: fix memory leak in tipc_link_xmit (bsc#1242521).
• CVE-2025-37781: i2c: cros-ec-tunnel: defer probe if parent EC is not present (bsc#1242575).
• CVE-2025-37800: driver core: fix potential NULL pointer dereference in dev_uevent() (bsc#1242849).
• CVE-2025-37810: usb: dwc3: gadget: check that event count does not exceed event buffer length (bsc#1242906).
• CVE-2025-37836: PCI: Fix reference…