{"schema_version":"1.7.2","id":"OESA-2025-2468","modified":"2025-10-17T14:55:54Z","published":"2025-10-17T14:55:54Z","upstream":["CVE-2022-50251","CVE-2022-50278","CVE-2022-50290","CVE-2022-50347","CVE-2022-50386","CVE-2022-50410","CVE-2022-50414","CVE-2022-50521","CVE-2022-50538","CVE-2023-53220","CVE-2023-53226","CVE-2023-53229","CVE-2023-53234","CVE-2023-53480","CVE-2023-53625","CVE-2025-38700","CVE-2025-38709","CVE-2025-39683"],"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\nmmc: vub300: fix return value check of mmc_add_host()\n\nmmc_add_host() may return error, if we ignore its return value, the memory\nthat allocated in mmc_alloc_host() will be leaked and it will lead a kernel\ncrash because of deleting not added device in the remove path.\n\nSo fix this by checking the return value and goto error path which will call\nmmc_free_host(), besides, the timer added before mmc_add_host() needs be del.\n\nAnd this patch fixes another missing call mmc_free_host() if usb_control_msg()\nfails.(CVE-2022-50251)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPNP: fix name memory leak in pnp_alloc_dev()\n\nAfter commit 1fa5ae857bb1 ("driver core: get rid of struct device's\nbus_id string array"), the name of device is allocated dynamically,\nmove dev_set_name() after pnp_add_id() to avoid memory leak.(CVE-2022-50278)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2022-50290)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host()\n\nmmc_add_host() may return error, if we ignore its return value, the memory\nthat allocated in mmc_alloc_host() will be leaked and it will lead a kernel\ncrash because of deleting not added device in the remove path.\n\nSo fix this by checking the return value and calling mmc_free_host() in the\nerror path, besides, led_classdev_unregister() and pm_runtime_disable() also\nneed be called.(CVE-2022-50347)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix user-after-free\n\nThis uses l2cap_chan_hold_unless_zero() after calling\n__l2cap_get_chan_blah() to prevent the following trace:\n\nBluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref\n*kref)\nBluetooth: chan 0000000023c4974d\nBluetooth: parent 00000000ae861c08\n==================================================================\nBUG: KASAN: use-after-free in __mutex_waiter_is_first\nkernel/locking/mutex.c:191 [inline]\nBUG: KASAN: use-after-free in __mutex_lock_common\nkernel/locking/mutex.c:671 [inline]\nBUG: KASAN: use-after-free in __mutex_lock+0x278/0x400\nkernel/locking/mutex.c:729\nRead of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389(CVE-2022-50386)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Protect against send buffer overflow in NFSv2 READ\n\nSince before the git era, NFSD has conserved the number of pages\nheld by each nfsd thread by combining the RPC receive and send\nbuffers into a single array of pages. This works because there are\nno cases where an operation needs a large RPC Call message and a\nlarge RPC Reply at the same time.\n\nOnce an RPC Call has been received, svc_process() updates\nsvc_rqst::rq_res to describe the part of rq_pages that can be\nused for constructing the Reply. This means that the send buffer\n(rq_res) shrinks when the received RPC record containing the RPC\nCall is large.\n\nA client can force this shrinkage on TCP by sending a correctly-\nformed RPC Call header contained in an RPC record that is\nexcessively large. The full maximum payload size cannot be\nconstructed in that case.(CVE-2022-50410)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: fcoe: Fix transport not deattached when fcoe_if_init() fails\n\nfcoe_init() calls fcoe_transport_attach(&fcoe_sw_transport), but when\nfcoe_if_init() fails, &fcoe_sw_transport is not detached and leaves freed\n&fcoe_sw_transport on fcoe_transports list. This causes panic when\nreinserting module.\n\n BUG: unable to handle page fault for address: fffffbfff82e2213\n RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe]\n Call Trace:\n  <TASK>\n  do_one_initcall+0xd0/0x4e0\n  load_module+0x5eee/0x7210\n  ...(CVE-2022-50414)\n\nIn the Linux kernel, the mxm-wmi driver's mxm_wmi_call_mx[ds|mx]() function has a memory leak vulnerability. The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method() is not freed after the call, which leads to memory leak. Since the method results in ACPI buffer is not used, passing NULL to wmi_evaluate_method() fixes the memory leak.(CVE-2022-50521)\n\nIn the Linux kernel, a vulnerability exists in the VME subsystem's fake_init() function. The __root_device_register() function may fail but the error is not caught, which can cause failure when unregistering vme_root during exit, leading to null pointer dereference and potential system crash.(CVE-2022-50538)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: az6007: Fix null-ptr-deref in az6007_i2c_xfer()\n\nIn az6007_i2c_xfer, msg is controlled by user. When msg[i].buf\nis null and msg[i].len is zero, former checks on msg[i].buf would be\npassed. Malicious data finally reach az6007_i2c_xfer. If accessing\nmsg[i].buf[0] without sanity check, null ptr deref would happen.\nWe add check on msg[i].len to prevent crash.\n\nSimilar commit:\ncommit 0ed554fd769a\n("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")(CVE-2023-53220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: Fix OOB and integer underflow when rx packets\n\nMake sure mwifiex_process_mgmt_packet,\nmwifiex_process_sta_rx_packet and mwifiex_process_uap_rx_packet,\nmwifiex_uap_queue_bridged_pkt and mwifiex_process_rx_packet\nnot out-of-bounds access the skb->data buffer.(CVE-2023-53226)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded sta\n\nAvoid potential data corruption issues caused by uninitialized driver\nprivate data structures.(CVE-2023-53229)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwatchdog: Fix kmemleak in watchdog_cdev_register\n\nkmemleak reports memory leaks in watchdog_dev_register, as follows:\nunreferenced object 0xffff888116233000 (size 2048):\n  comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s)\n  hex dump (first 32 bytes):\n    80 fa b9 05 81 88 ff ff 08 30 23 16 81 88 ff ff  .........0#.....\n    08 30 23 16 81 88 ff ff 00 00 00 00 00 00 00 00  .0#.............\n  backtrace:\n    [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220\n    [<000000006a389304>] kmalloc_trace+0x21/0x110\n    [<000000008d640eea>] watchdog_dev_register+0x4e/0x780 [watchdog]\n    [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog]\n    [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog]\n    [<000000001f730178>] 0xffffffffc10880ae\n    [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0\n    [<00000000b98be325>] do_init_module+0x1ca/0x5f0\n    [<0000000046d08e7c>] load_module+0x6133/0x70f0\n    ...\n\nunreferenced object 0xffff888105b9fa80 (size 16):\n  comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s)\n  hex dump (first 16 bytes):\n    77 61 74 63 68 64 6f 67 31 00 b9 05 81 88 ff ff  watchdog1.......\n  backtrace:\n    [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220\n    [<00000000486ab89b>] __kmalloc_node_track_caller+0x44/0x1b0\n    [<000000005a39aab0>] kvasprintf+0xb5/0x140\n    [<0000000024806f85>] kvasprintf_const+0x55/0x180\n    [<000000009276cb7f>] kobject_set_name_vargs+0x56/0x150\n    [<00000000a92e820b>] dev_set_name+0xab/0xe0\n    [<00000000cec812c6>] watchdog_dev_register+0x285/0x780 [watchdog]\n    [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog]\n    [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog]\n    [<000000001f730178>] 0xffffffffc10880ae\n    [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0\n    [<00000000b98be325>] do_init_module+0x1ca/0x5f0\n    [<0000000046d08e7c>] load_module+0x6133/0x70f0\n    ...\n\nThe reason is that put_device is not be called if cdev_device_add fails\nand wdd->id != 0.\n\nwatchdog_cdev_register\n  wd_data = kzalloc                             [1]\n  err = dev_set_name                            [2]\n  ..\n  err = cdev_device_add\n  if (err) {\n    if (wdd->id == 0) {  // wdd->id != 0\n      ..\n    }\n    return err;  // [1],[2] would be leaked\n\nTo fix it, call put_device in all wdd->id cases.(CVE-2023-53234)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkobject: Add sanity check for kset->kobj.ktype in kset_register()\n\nWhen I register a kset in the following way:\n\tstatic struct kset my_kset;\n\tkobject_set_name(&my_kset.kobj, "my_kset");\n        ret = kset_register(&my_kset);\n\nA null pointer dereference exception is occurred:\n[ 4453.568337] Unable to handle kernel NULL pointer dereference at \\\nvirtual address 0000000000000028\n... ...\n[ 4453.810361] Call trace:\n[ 4453.813062]  kobject_get_ownership+0xc/0x34\n[ 4453.817493]  kobject_add_internal+0x98/0x274\n[ 4453.822005]  kset_register+0x5c/0xb4\n[ 4453.825820]  my_kobj_init+0x44/0x1000 [my_kset]\n... ...\n\nBecause I didn't initialize my_kset.kobj.ktype.\n\nAccording to the description in Documentation/core-api/kobject.rst:\n - A ktype is the type of object that embeds a kobject.  Every structure\n   that embeds a kobject needs a corresponding ktype.\n\nSo add sanity check to make sure kset->kobj.ktype is not NULL.(CVE-2023-53480)\n\nA vulnerability was found in the Linux kernel's drm/i915/gvt module. The issue occurs during vgpu debugfs cleanup process. When destroying vgpu, the code doesn't properly check if the root debugfs is available. In remove cases, the drm minor's debugfs root might already be destroyed, which leads to kernel NULL pointer dereference and causes kernel oops as shown in the description.(CVE-2023-53625)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated\n\nIn case of an ib_fast_reg_mr allocation failure during iSER setup, the\nmachine hits a panic because iscsi_conn->dd_data is initialized\nunconditionally, even when no memory is allocated (dd_size == 0).  This\nleads invalid pointer dereference during connection teardown.\n\nFix by setting iscsi_conn->dd_data only if memory is actually allocated.\n\nPanic trace:\n------------\n iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12\n iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers\n BUG: unable to handle page fault for address: fffffffffffffff8\n RIP: 0010:swake_up_locked.part.5+0xa/0x40\n Call Trace:\n  complete+0x31/0x40\n  iscsi_iser_conn_stop+0x88/0xb0 [ib_iser]\n  iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi]\n  iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi]\n  iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi]\n  ? netlink_lookup+0x12f/0x1b0\n  ? netlink_deliver_tap+0x2c/0x200\n  netlink_unicast+0x1ab/0x280\n  netlink_sendmsg+0x257/0x4f0\n  ? _copy_from_user+0x29/0x60\n  sock_sendmsg+0x5f/0x70(CVE-2025-38700)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nloop: Avoid updating block size under exclusive owner\n\nSyzbot came up with a reproducer where a loop device block size is\nchanged underneath a mounted filesystem. This causes a mismatch between\nthe block device block size and the block size stored in the superblock\ncausing confusion in various places such as fs/buffer.c. The particular\nissue triggered by syzbot was a warning in __getblk_slow() due to\nrequested buffer size not matching block device block size.\n\nFix the problem by getting exclusive hold of the loop device to change\nits block size. This fails if somebody (such as filesystem) has already\nan exclusive ownership of the block device and thus prevents modifying\nthe loop device under some exclusive owner which doesn't expect it.(CVE-2025-38709)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Limit access to parser->buffer when trace_get_user failed\n\nWhen the length of the string written to set_ftrace_filter exceeds\nFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:\n\nBUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0\nRead of size 1 at addr ffff0000d00bd5ba by task ash/165\n\nCPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty\nHardware name: linux,dummy-virt (DT)\nCall trace:\n show_stack+0x34/0x50 (C)\n dump_stack_lvl+0xa0/0x158\n print_address_description.constprop.0+0x88/0x398\n print_report+0xb0/0x280\n kasan_report+0xa4/0xf0\n __asan_report_load1_noabort+0x20/0x30\n strsep+0x18c/0x1b0\n ftrace_process_regex.isra.0+0x100/0x2d8\n ftrace_regex_release+0x484/0x618\n __fput+0x364/0xa58\n ____fput+0x28/0x40\n task_work_run+0x154/0x278\n do_notify_resume+0x1f0/0x220\n el0_svc+0xec/0xf0\n el0t_64_sync_handler+0xa0/0xe8\n el0t_64_sync+0x1ac/0x1b0\n\nThe reason is that trace_get_user will fail when processing a string\nlonger than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0.\nThen an OOB access will be triggered in ftrace_regex_release->\nftrace_process_regex->strsep->strpbrk. We can solve this problem by\nlimiting access to parser->buffer when trace_get_user failed.(CVE-2025-39683)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2510.2.0.0347.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","kernel-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","perf-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2510.2.0.0347.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2510.2.0.0347.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","kernel-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","perf-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2510.2.0.0347.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50251"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50278"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50290"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50347"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50386"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50410"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50414"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50521"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50538"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53220"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53226"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53229"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53234"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53480"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53625"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38700"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38709"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39683"}],"database_specific":{"severity":"High"}}