{"schema_version":"1.7.2","id":"OESA-2025-1726","modified":"2025-07-04T14:43:05Z","published":"2025-07-04T14:43:05Z","upstream":["CVE-2022-49814","CVE-2022-49917","CVE-2022-49981","CVE-2022-49982","CVE-2022-50080","CVE-2022-50094","CVE-2022-50203","CVE-2022-50222","CVE-2023-53053","CVE-2023-53062","CVE-2023-53066","CVE-2023-53125","CVE-2025-38058"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkcm: close race conditions on sk_receive_queue\n\nsk-\u0026gt;sk_receive_queue is protected by skb queue lock, but for KCM\nsockets its RX path takes mux-\u0026gt;rx_lock to protect more than just\nskb queue. However, kcm_recvmsg() still only grabs the skb queue\nlock, so race conditions still exist.\n\nWe can teach kcm_recvmsg() to grab mux-\u0026gt;rx_lock too but this would\nintroduce a potential performance regression as struct kcm_mux can\nbe shared by multiple KCM sockets.\n\nSo we have to enforce skb queue lock in requeue_rx_msgs() and handle\nskb peek case carefully in kcm_wait_data(). Fortunately,\nskb_recv_datagram() already handles it nicely and is widely used by\nother sockets, we can just switch to skb_recv_datagram() after\ngetting rid of the unnecessary sock lock in kcm_recvmsg() and\nkcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,\nso it is safe to get rid of this check too.\n\nI ran the original syzbot reproducer for 30 min without seeing any\nissue.(CVE-2022-49814)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix WARNING in ip_vs_app_net_cleanup()\n\nDuring the initialization of ip_vs_app_net_init(), if file ip_vs_app\nfails to be created, the initialization is successful by default.\nTherefore, the ip_vs_app file doesn\u0026apos;t be found during the remove in\nip_vs_app_net_cleanup(). It will cause WRNING.\n\nThe following is the stack information:\nname \u0026apos;ip_vs_app\u0026apos;\nWARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460\nModules linked in:\nWorkqueue: netns cleanup_net\nRIP: 0010:remove_proc_entry+0x389/0x460\nCall Trace:\n\u0026lt;TASK\u0026gt;\nops_exit_list+0x125/0x170\ncleanup_net+0x4ea/0xb00\nprocess_one_work+0x9bf/0x1710\nworker_thread+0x665/0x1080\nkthread+0x2e4/0x3a0\nret_from_fork+0x1f/0x30\n\u0026lt;/TASK\u0026gt;(CVE-2022-49917)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: hidraw: fix memory leak in hidraw_release()\n\nFree the buffered reports before deleting the list entry.\n\nBUG: memory leak\nunreferenced object 0xffff88810e72f180 (size 32):\n  comm \u0026quot;softirq\u0026quot;, pid 0, jiffies 4294945143 (age 16.080s)\n  hex dump (first 32 bytes):\n    64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00  d..j............\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [\u0026lt;ffffffff814ac6c3\u0026gt;] kmemdup+0x23/0x50 mm/util.c:128\n    [\u0026lt;ffffffff8357c1d2\u0026gt;] kmemdup include/linux/fortify-string.h:440 [inline]\n    [\u0026lt;ffffffff8357c1d2\u0026gt;] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521\n    [\u0026lt;ffffffff8356ddad\u0026gt;] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992\n    [\u0026lt;ffffffff8356e41e\u0026gt;] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065\n    [\u0026lt;ffffffff835f0d3f\u0026gt;] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284\n    [\u0026lt;ffffffff82d3c7f9\u0026gt;] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670\n    [\u0026lt;ffffffff82d3cc26\u0026gt;] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747\n    [\u0026lt;ffffffff82ef1e14\u0026gt;] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988\n    [\u0026lt;ffffffff812f50a8\u0026gt;] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474\n    [\u0026lt;ffffffff812f5586\u0026gt;] expire_timers kernel/time/timer.c:1519 [inline]\n    [\u0026lt;ffffffff812f5586\u0026gt;] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790\n    [\u0026lt;ffffffff812f56e4\u0026gt;] __run_timers kernel/time/timer.c:1768 [inline]\n    [\u0026lt;ffffffff812f56e4\u0026gt;] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803\n    [\u0026lt;ffffffff848000e6\u0026gt;] __do_softirq+0xe6/0x2ea kernel/softirq.c:571\n    [\u0026lt;ffffffff81246db0\u0026gt;] invoke_softirq kernel/softirq.c:445 [inline]\n    [\u0026lt;ffffffff81246db0\u0026gt;] __irq_exit_rcu kernel/softirq.c:650 [inline]\n    [\u0026lt;ffffffff81246db0\u0026gt;] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662\n    [\u0026lt;ffffffff84574f02\u0026gt;] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106\n    [\u0026lt;ffffffff84600c8b\u0026gt;] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649\n    [\u0026lt;ffffffff8458a070\u0026gt;] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline]\n    [\u0026lt;ffffffff8458a070\u0026gt;] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline]\n    [\u0026lt;ffffffff8458a070\u0026gt;] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline]\n    [\u0026lt;ffffffff8458a070\u0026gt;] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554(CVE-2022-49981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: pvrusb2: fix memory leak in pvr_probe\n\nThe error handling code in pvr2_hdw_create forgets to unregister the\nv4l2 device. When pvr2_hdw_create returns back to pvr2_context_create,\nit calls pvr2_context_destroy to destroy context, but mp-\u0026gt;hdw is NULL,\nwhich leads to that pvr2_hdw_destroy directly returns.\n\nFix this by adding v4l2_device_unregister to decrease the refcount of\nusb interface.(CVE-2022-49982)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntee: add overflow check in register_shm_helper()\n\nWith special lengths supplied by user space, register_shm_helper() has\nan integer overflow when calculating the number of pages covered by a\nsupplied user space memory region.\n\nThis causes internal_get_user_pages_fast() a helper function of\npin_user_pages_fast() to do a NULL pointer dereference:\n\n  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010\n  Modules linked in:\n  CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11\n  Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015\n  pc : internal_get_user_pages_fast+0x474/0xa80\n  Call trace:\n   internal_get_user_pages_fast+0x474/0xa80\n   pin_user_pages_fast+0x24/0x4c\n   register_shm_helper+0x194/0x330\n   tee_shm_register_user_buf+0x78/0x120\n   tee_ioctl+0xd0/0x11a0\n   __arm64_sys_ioctl+0xa8/0xec\n   invoke_syscall+0x48/0x114\n\nFix this by adding an an explicit call to access_ok() in\ntee_shm_register_user_buf() to catch an invalid user space address\nearly.(CVE-2022-50080)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspmi: trace: fix stack-out-of-bound access in SPMI tracing functions\n\ntrace_spmi_write_begin() and trace_spmi_read_end() both call\nmemcpy() with a length of \u0026quot;len + 1\u0026quot;.  This leads to one extra\nbyte being read beyond the end of the specified buffer.  Fix\nthis out-of-bound memory access by using a length of \u0026quot;len\u0026quot;\ninstead.\n\nHere is a KASAN log showing the issue:\n\nBUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234\nRead of size 2 at addr ffffffc0265b7540 by task (CVE-2022-50094)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: OMAP2+: display: Fix refcount leak bug\n\nIn omapdss_init_fbdev(), of_find_node_by_name() will return a node\npointer with refcount incremented. We should use of_node_put() when\nit is not used anymore.(CVE-2022-50203)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntty: vt: initialize unicode screen buffer\n\nsyzbot reports kernel infoleak at vcs_read() [1], for buffer can be read\nimmediately after resize operation. Initialize buffer using kzalloc().\n\n  ----------\n  #include \u0026lt;fcntl.h\u0026gt;\n  #include \u0026lt;unistd.h\u0026gt;\n  #include \u0026lt;sys/ioctl.h\u0026gt;\n  #include \u0026lt;linux/fb.h\u0026gt;\n\n  int main(int argc, char *argv[])\n  {\n    struct fb_var_screeninfo var = { };\n    const int fb_fd = open(\u0026quot;/dev/fb0\u0026quot;, 3);\n    ioctl(fb_fd, FBIOGET_VSCREENINFO, \u0026amp;var);\n    var.yres = 0x21;\n    ioctl(fb_fd, FBIOPUT_VSCREENINFO, \u0026amp;var);\n    return read(open(\u0026quot;/dev/vcsu\u0026quot;, O_RDONLY), \u0026amp;var, sizeof(var)) == -1;\n  }\n  ----------(CVE-2022-50222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerspan: do not use skb_mac_header() in ndo_start_xmit()\n\nDrivers should not assume skb_mac_header(skb) == skb-\u0026gt;data in their\nndo_start_xmit().\n\nUse skb_network_offset() and skb_transport_offset() which\nbetter describe what is needed in erspan_fb_xmit() and\nip6erspan_tunnel_xmit()\n\nsyzbot reported:\nWARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline]\nWARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962\nModules linked in:\nCPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023\nRIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline]\nRIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962\nCode: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 \u0026lt;0f\u0026gt; 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00\nRSP: 0018:ffffc90003b2f830 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000\nRDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003\nRBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffff\nR10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00\nR13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff888023408000\nFS: 0000555556a61300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055e5b11eb6e8 CR3: 0000000027c1b000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u0026lt;TASK\u0026gt;\n__netdev_start_xmit include/linux/netdevice.h:4900 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4914 [inline]\n__dev_direct_xmit+0x504/0x730 net/core/dev.c:4300\ndev_direct_xmit include/linux/netdevice.h:3088 [inline]\npacket_xmit+0x20a/0x390 net/packet/af_packet.c:285\npacket_snd net/packet/af_packet.c:3075 [inline]\npacket_sendmsg+0x31a0/0x5150 net/packet/af_packet.c:3107\nsock_sendmsg_nosec net/socket.c:724 [inline]\nsock_sendmsg+0xde/0x190 net/socket.c:747\n__sys_sendto+0x23a/0x340 net/socket.c:2142\n__do_sys_sendto net/socket.c:2154 [inline]\n__se_sys_sendto net/socket.c:2150 [inline]\n__x64_sys_sendto+0xe1/0x1b0 net/socket.c:2150\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7f123aaa1039\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffc15d12058 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f123aaa1039\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 0000000000000000 R08: 0000000020000040 R09: 0000000000000014\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f123aa648c0\nR13: 431bde82d7b634db R14: 0000000000000000 R15: 0000000000000000(CVE-2023-53053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: smsc95xx: Limit packet length to skb-\u0026gt;len\n\nPacket length retrieved from descriptor may be larger than\nthe actual socket buffer length. In such case the cloned\nskb passed up the network stack will leak kernel memory contents.(CVE-2023-53062)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info\n\nWe have to make sure that the info returned by the helper is valid\nbefore using it.\n\nFound by Linux Verification Center (linuxtesting.org) with the SVACE\nstatic analysis tool.(CVE-2023-53066)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: smsc75xx: Limit packet length to skb-\u0026gt;len\n\nPacket length retrieved from skb data may be larger than\nthe actual socket buffer length (up to 9026 bytes). In such\ncase the cloned skb passed up the network stack will leak\nkernel memory contents.(CVE-2023-53125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock\n\n... or we risk stealing final mntput from sync umount - raising mnt_count\nafter umount(2) has verified that victim is not busy, but before it\nhas set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn\u0026apos;t see\nthat it\u0026apos;s safe to quietly undo mnt_count increment and leaves dropping\nthe reference to caller, where it\u0026apos;ll be a full-blown mntput().\n\nCheck under mount_lock is needed; leaving the current one done before\ntaking that makes no sense - it\u0026apos;s nowhere near common enough to bother\nwith.(CVE-2025-38058)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2507.1.0.0334.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","kernel-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","perf-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2507.1.0.0334.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2507.1.0.0334.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","kernel-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","perf-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2507.1.0.0334.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1726"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49814"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49917"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49981"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49982"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50080"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50094"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50203"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50222"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53053"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53062"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53066"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53125"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38058"}],"database_specific":{"severity":"High"}}