An update for kernel is now available for openEuler-20.03-LTS-SP4 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2025-2468 Final 1.0 1.0 2025-10-17 Initial 2025-10-17 2025-10-17 openEuler SA Tool V1.0 2025-10-17 kernel security update An update for kernel is now available for openEuler-20.03-LTS-SP4 The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, the timer added before mmc_add_host() needs be del. And this patch fixes another missing call mmc_free_host() if usb_control_msg() fails.(CVE-2022-50251) In the Linux kernel, the following vulnerability has been resolved: PNP: fix name memory leak in pnp_alloc_dev() After commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, move dev_set_name() after pnp_add_id() to avoid memory leak.(CVE-2022-50278) Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2022-50290) In the Linux kernel, the following vulnerability has been resolved: mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path, besides, led_classdev_unregister() and pm_runtime_disable() also need be called.(CVE-2022-50347) In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix user-after-free This uses l2cap_chan_hold_unless_zero() after calling __l2cap_get_chan_blah() to prevent the following trace: Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref *kref) Bluetooth: chan 0000000023c4974d Bluetooth: parent 00000000ae861c08 ================================================================== BUG: KASAN: use-after-free in __mutex_waiter_is_first kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in __mutex_lock_common kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in __mutex_lock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389(CVE-2022-50386) In the Linux kernel, the following vulnerability has been resolved: NFSD: Protect against send buffer overflow in NFSv2 READ Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply at the same time. Once an RPC Call has been received, svc_process() updates svc_rqst::rq_res to describe the part of rq_pages that can be used for constructing the Reply. This means that the send buffer (rq_res) shrinks when the received RPC record containing the RPC Call is large. A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case.(CVE-2022-50410) In the Linux kernel, the following vulnerability has been resolved: scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails fcoe_init() calls fcoe_transport_attach(&fcoe_sw_transport), but when fcoe_if_init() fails, &fcoe_sw_transport is not detached and leaves freed &fcoe_sw_transport on fcoe_transports list. This causes panic when reinserting module. BUG: unable to handle page fault for address: fffffbfff82e2213 RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe] Call Trace: <TASK> do_one_initcall+0xd0/0x4e0 load_module+0x5eee/0x7210 ...(CVE-2022-50414) In 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) In 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) In the Linux kernel, the following vulnerability has been resolved: media: az6007: Fix null-ptr-deref in az6007_i2c_xfer() In az6007_i2c_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach az6007_i2c_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")(CVE-2023-53220) In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix OOB and integer underflow when rx packets Make sure mwifiex_process_mgmt_packet, mwifiex_process_sta_rx_packet and mwifiex_process_uap_rx_packet, mwifiex_uap_queue_bridged_pkt and mwifiex_process_rx_packet not out-of-bounds access the skb->data buffer.(CVE-2023-53226) In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded sta Avoid potential data corruption issues caused by uninitialized driver private data structures.(CVE-2023-53229) In the Linux kernel, the following vulnerability has been resolved: watchdog: Fix kmemleak in watchdog_cdev_register kmemleak reports memory leaks in watchdog_dev_register, as follows: unreferenced object 0xffff888116233000 (size 2048): comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 32 bytes): 80 fa b9 05 81 88 ff ff 08 30 23 16 81 88 ff ff .........0#..... 08 30 23 16 81 88 ff ff 00 00 00 00 00 00 00 00 .0#............. backtrace: [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<000000006a389304>] kmalloc_trace+0x21/0x110 [<000000008d640eea>] watchdog_dev_register+0x4e/0x780 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 ... unreferenced object 0xffff888105b9fa80 (size 16): comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 16 bytes): 77 61 74 63 68 64 6f 67 31 00 b9 05 81 88 ff ff watchdog1....... backtrace: [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<00000000486ab89b>] __kmalloc_node_track_caller+0x44/0x1b0 [<000000005a39aab0>] kvasprintf+0xb5/0x140 [<0000000024806f85>] kvasprintf_const+0x55/0x180 [<000000009276cb7f>] kobject_set_name_vargs+0x56/0x150 [<00000000a92e820b>] dev_set_name+0xab/0xe0 [<00000000cec812c6>] watchdog_dev_register+0x285/0x780 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 ... The reason is that put_device is not be called if cdev_device_add fails and wdd->id != 0. watchdog_cdev_register wd_data = kzalloc [1] err = dev_set_name [2] .. err = cdev_device_add if (err) { if (wdd->id == 0) { // wdd->id != 0 .. } return err; // [1],[2] would be leaked To fix it, call put_device in all wdd->id cases.(CVE-2023-53234) In the Linux kernel, the following vulnerability has been resolved: kobject: Add sanity check for kset->kobj.ktype in kset_register() When I register a kset in the following way: static struct kset my_kset; kobject_set_name(&my_kset.kobj, "my_kset"); ret = kset_register(&my_kset); A null pointer dereference exception is occurred: [ 4453.568337] Unable to handle kernel NULL pointer dereference at \ virtual address 0000000000000028 ... ... [ 4453.810361] Call trace: [ 4453.813062] kobject_get_ownership+0xc/0x34 [ 4453.817493] kobject_add_internal+0x98/0x274 [ 4453.822005] kset_register+0x5c/0xb4 [ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset] ... ... Because I didn't initialize my_kset.kobj.ktype. According to the description in Documentation/core-api/kobject.rst: - A ktype is the type of object that embeds a kobject. Every structure that embeds a kobject needs a corresponding ktype. So add sanity check to make sure kset->kobj.ktype is not NULL.(CVE-2023-53480) A 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) In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated In case of an ib_fast_reg_mr allocation failure during iSER setup, the machine hits a panic because iscsi_conn->dd_data is initialized unconditionally, even when no memory is allocated (dd_size == 0). This leads invalid pointer dereference during connection teardown. Fix by setting iscsi_conn->dd_data only if memory is actually allocated. Panic trace: ------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70(CVE-2025-38700) In the Linux kernel, the following vulnerability has been resolved: loop: Avoid updating block size under exclusive owner Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size. Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it.(CVE-2025-38709) In the Linux kernel, the following vulnerability has been resolved: tracing: Limit access to parser->buffer when trace_get_user failed When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered: BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165 CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0 The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed.(CVE-2025-39683) An update for kernel is now available for openEuler-20.03-LTS-SP4. openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. High kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50251 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50278 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50290 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50347 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50386 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50410 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50414 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50521 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50538 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-53220 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-53226 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-53229 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-53234 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-53480 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-53625 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38700 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38709 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39683 https://nvd.nist.gov/vuln/detail/CVE-2022-50251 https://nvd.nist.gov/vuln/detail/CVE-2022-50278 https://nvd.nist.gov/vuln/detail/CVE-2022-50290 https://nvd.nist.gov/vuln/detail/CVE-2022-50347 https://nvd.nist.gov/vuln/detail/CVE-2022-50386 https://nvd.nist.gov/vuln/detail/CVE-2022-50410 https://nvd.nist.gov/vuln/detail/CVE-2022-50414 https://nvd.nist.gov/vuln/detail/CVE-2022-50521 https://nvd.nist.gov/vuln/detail/CVE-2022-50538 https://nvd.nist.gov/vuln/detail/CVE-2023-53220 https://nvd.nist.gov/vuln/detail/CVE-2023-53226 https://nvd.nist.gov/vuln/detail/CVE-2023-53229 https://nvd.nist.gov/vuln/detail/CVE-2023-53234 https://nvd.nist.gov/vuln/detail/CVE-2023-53480 https://nvd.nist.gov/vuln/detail/CVE-2023-53625 https://nvd.nist.gov/vuln/detail/CVE-2025-38700 https://nvd.nist.gov/vuln/detail/CVE-2025-38709 https://nvd.nist.gov/vuln/detail/CVE-2025-39683 openEuler-20.03-LTS-SP4 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 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 kernel-4.19.90-2510.2.0.0347.oe2003sp4.src.rpm In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, the timer added before mmc_add_host() needs be del. And this patch fixes another missing call mmc_free_host() if usb_control_msg() fails. 2025-10-17 CVE-2022-50251 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In the Linux kernel, the following vulnerability has been resolved: PNP: fix name memory leak in pnp_alloc_dev() After commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, move dev_set_name() after pnp_add_id() to avoid memory leak. 2025-10-17 CVE-2022-50278 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. 2025-10-17 CVE-2022-50290 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In the Linux kernel, the following vulnerability has been resolved: mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path, besides, led_classdev_unregister() and pm_runtime_disable() also need be called. 2025-10-17 CVE-2022-50347 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix user-after-free This uses l2cap_chan_hold_unless_zero() after calling __l2cap_get_chan_blah() to prevent the following trace: Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref *kref) Bluetooth: chan 0000000023c4974d Bluetooth: parent 00000000ae861c08 ================================================================== BUG: KASAN: use-after-free in __mutex_waiter_is_first kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in __mutex_lock_common kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in __mutex_lock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389 2025-10-17 CVE-2022-50386 openEuler-20.03-LTS-SP4 High 7.6 AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In the Linux kernel, the following vulnerability has been resolved: NFSD: Protect against send buffer overflow in NFSv2 READ Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply at the same time. Once an RPC Call has been received, svc_process() updates svc_rqst::rq_res to describe the part of rq_pages that can be used for constructing the Reply. This means that the send buffer (rq_res) shrinks when the received RPC record containing the RPC Call is large. A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case. 2025-10-17 CVE-2022-50410 openEuler-20.03-LTS-SP4 High 7.1 AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In the Linux kernel, the following vulnerability has been resolved: scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails fcoe_init() calls fcoe_transport_attach(&fcoe_sw_transport), but when fcoe_if_init() fails, &fcoe_sw_transport is not detached and leaves freed &fcoe_sw_transport on fcoe_transports list. This causes panic when reinserting module. BUG: unable to handle page fault for address: fffffbfff82e2213 RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe] Call Trace: <TASK> do_one_initcall+0xd0/0x4e0 load_module+0x5eee/0x7210 ... 2025-10-17 CVE-2022-50414 openEuler-20.03-LTS-SP4 Medium 4.4 AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In 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. 2025-10-17 CVE-2022-50521 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In 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. 2025-10-17 CVE-2022-50538 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In the Linux kernel, the following vulnerability has been resolved: media: az6007: Fix null-ptr-deref in az6007_i2c_xfer() In az6007_i2c_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach az6007_i2c_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()") 2025-10-17 CVE-2023-53220 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix OOB and integer underflow when rx packets Make sure mwifiex_process_mgmt_packet, mwifiex_process_sta_rx_packet and mwifiex_process_uap_rx_packet, mwifiex_uap_queue_bridged_pkt and mwifiex_process_rx_packet not out-of-bounds access the skb->data buffer. 2025-10-17 CVE-2023-53226 openEuler-20.03-LTS-SP4 High 7.1 AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded sta Avoid potential data corruption issues caused by uninitialized driver private data structures. 2025-10-17 CVE-2023-53229 openEuler-20.03-LTS-SP4 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In the Linux kernel, the following vulnerability has been resolved: watchdog: Fix kmemleak in watchdog_cdev_register kmemleak reports memory leaks in watchdog_dev_register, as follows: unreferenced object 0xffff888116233000 (size 2048): comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 32 bytes): 80 fa b9 05 81 88 ff ff 08 30 23 16 81 88 ff ff .........0#..... 08 30 23 16 81 88 ff ff 00 00 00 00 00 00 00 00 .0#............. backtrace: [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<000000006a389304>] kmalloc_trace+0x21/0x110 [<000000008d640eea>] watchdog_dev_register+0x4e/0x780 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 ... unreferenced object 0xffff888105b9fa80 (size 16): comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 16 bytes): 77 61 74 63 68 64 6f 67 31 00 b9 05 81 88 ff ff watchdog1....... backtrace: [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<00000000486ab89b>] __kmalloc_node_track_caller+0x44/0x1b0 [<000000005a39aab0>] kvasprintf+0xb5/0x140 [<0000000024806f85>] kvasprintf_const+0x55/0x180 [<000000009276cb7f>] kobject_set_name_vargs+0x56/0x150 [<00000000a92e820b>] dev_set_name+0xab/0xe0 [<00000000cec812c6>] watchdog_dev_register+0x285/0x780 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 ... The reason is that put_device is not be called if cdev_device_add fails and wdd->id != 0. watchdog_cdev_register wd_data = kzalloc [1] err = dev_set_name [2] .. err = cdev_device_add if (err) { if (wdd->id == 0) { // wdd->id != 0 .. } return err; // [1],[2] would be leaked To fix it, call put_device in all wdd->id cases. 2025-10-17 CVE-2023-53234 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In the Linux kernel, the following vulnerability has been resolved: kobject: Add sanity check for kset->kobj.ktype in kset_register() When I register a kset in the following way: static struct kset my_kset; kobject_set_name(&my_kset.kobj, "my_kset"); ret = kset_register(&my_kset); A null pointer dereference exception is occurred: [ 4453.568337] Unable to handle kernel NULL pointer dereference at \ virtual address 0000000000000028 ... ... [ 4453.810361] Call trace: [ 4453.813062] kobject_get_ownership+0xc/0x34 [ 4453.817493] kobject_add_internal+0x98/0x274 [ 4453.822005] kset_register+0x5c/0xb4 [ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset] ... ... Because I didn't initialize my_kset.kobj.ktype. According to the description in Documentation/core-api/kobject.rst: - A ktype is the type of object that embeds a kobject. Every structure that embeds a kobject needs a corresponding ktype. So add sanity check to make sure kset->kobj.ktype is not NULL. 2025-10-17 CVE-2023-53480 openEuler-20.03-LTS-SP4 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 A 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. 2025-10-17 CVE-2023-53625 openEuler-20.03-LTS-SP4 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated In case of an ib_fast_reg_mr allocation failure during iSER setup, the machine hits a panic because iscsi_conn->dd_data is initialized unconditionally, even when no memory is allocated (dd_size == 0). This leads invalid pointer dereference during connection teardown. Fix by setting iscsi_conn->dd_data only if memory is actually allocated. Panic trace: ------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70 2025-10-17 CVE-2025-38700 openEuler-20.03-LTS-SP4 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In the Linux kernel, the following vulnerability has been resolved: loop: Avoid updating block size under exclusive owner Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size. Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it. 2025-10-17 CVE-2025-38709 openEuler-20.03-LTS-SP4 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468 In the Linux kernel, the following vulnerability has been resolved: tracing: Limit access to parser->buffer when trace_get_user failed When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered: BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165 CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0 The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed. 2025-10-17 CVE-2025-39683 openEuler-20.03-LTS-SP4 Medium 4.4 AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-10-17 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2468