An update for kernel is now available for openEuler-22.03-LTS-SP3 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2025-1872 Final 1.0 1.0 2025-07-18 Initial 2025-07-18 2025-07-18 openEuler SA Tool V1.0 2025-07-18 kernel security update An update for kernel is now available for openEuler-22.03-LTS-SP3 The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Treat NX as a valid SPTE bit for NPT Treat the NX bit as valid when using NPT, as KVM will set the NX bit when the NX huge page mitigation is enabled (mindblowing) and trigger the WARN that fires on reserved SPTE bits being set. KVM has required NX support for SVM since commit b26a71a1a5b9 ("KVM: SVM: Refuse to load kvm_amd if NX support is not available") for exactly this reason, but apparently it never occurred to anyone to actually test NPT with the mitigation enabled. ------------[ cut here ]------------ spte = 0x800000018a600ee7, level = 2, rsvd bits = 0x800f0000001fe000 WARNING: CPU: 152 PID: 15966 at arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm] Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/27/2022 RIP: 0010:make_spte+0x327/0x340 [kvm] Call Trace: <TASK> tdp_mmu_map_handle_target_level+0xc3/0x230 [kvm] kvm_tdp_mmu_map+0x343/0x3b0 [kvm] direct_page_fault+0x1ae/0x2a0 [kvm] kvm_tdp_page_fault+0x7d/0x90 [kvm] kvm_mmu_page_fault+0xfb/0x2e0 [kvm] npf_interception+0x55/0x90 [kvm_amd] svm_invoke_exit_handler+0x31/0xf0 [kvm_amd] svm_handle_exit+0xf6/0x1d0 [kvm_amd] vcpu_enter_guest+0xb6d/0xee0 [kvm] ? kvm_pmu_trigger_event+0x6d/0x230 [kvm] vcpu_run+0x65/0x2c0 [kvm] kvm_arch_vcpu_ioctl_run+0x355/0x610 [kvm] kvm_vcpu_ioctl+0x551/0x610 [kvm] __se_sys_ioctl+0x77/0xc0 __x64_sys_ioctl+0x1d/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> ---[ end trace 0000000000000000 ]---(CVE-2022-50224) In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Remove dangling pointers When an async control is written, we copy a pointer to the file handle that started the operation. That pointer will be used when the device is done. Which could be anytime in the future. If the user closes that file descriptor, its structure will be freed, and there will be one dangling pointer per pending async control, that the driver will try to use. Clean all the dangling pointers during release(). To avoid adding a performance penalty in the most common case (no async operation), a counter has been introduced with some logic to make sure that it is properly handled.(CVE-2024-58002) In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Don't reference skb after sending to VIOS Previously, after successfully flushing the xmit buffer to VIOS, the tx_bytes stat was incremented by the length of the skb. It is invalid to access the skb memory after sending the buffer to the VIOS because, at any point after sending, the VIOS can trigger an interrupt to free this memory. A race between reading skb->len and freeing the skb is possible (especially during LPM) and will result in use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic] Read of size 4 at addr c00000024eb48a70 by task hxecom/14495 <...> Call Trace: [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable) [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0 [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8 [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0 [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic] [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358 <...> Freed by task 0: kasan_save_stack+0x34/0x68 kasan_save_track+0x2c/0x50 kasan_save_free_info+0x64/0x108 __kasan_mempool_poison_object+0x148/0x2d4 napi_skb_cache_put+0x5c/0x194 net_tx_action+0x154/0x5b8 handle_softirqs+0x20c/0x60c do_softirq_own_stack+0x6c/0x88 <...> The buggy address belongs to the object at c00000024eb48a00 which belongs to the cache skbuff_head_cache of size 224 ==================================================================(CVE-2025-21855) A vulnerability classified as problematic was found in Linux Kernel up to 6.16-rc1 (Operating System).The CWE definition for the vulnerability is CWE-362. The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch 2790c4ec481be45a80948d059cd7c9a06bc37493/a1bf6a4e9264a685b0e642994031f9c5aad72414/110a47efcf23438ff8d31dbd9c854fae2a48bf98/f569984417a4e12c67366e69bdcb752970de921d/2a71924ca4af59ffc00f0444732b6cd54b153d0e/4b755305b2b0618e857fdadb499365b5f2e478d1/444ad445df5496a785705019268a8a84b84484bb/85a3e0ede38450ea3053b8c45d28cf55208409b8 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38108) A vulnerability was found in Linux Kernel up to 6.15.3 (Operating System). It has been rated as critical.Using CWE to declare the problem leads to CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.Impacted is confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch 5f1e1573bf103303944fd7225559de5d8297539c/b968ba8bfd9f90914957bbbd815413bf6a98eca7/74bc813d11c30e28fc5261dc877cca662ccfac68/78297d53d3878d43c1d627d20cd09f611fa4b91d/5180561afff8e0f029073c8c8117c95c6512d1f9/68c173ea138b66d7dd1fd980c9bc578a18e11884/b0b6bf90ce2699a574b3683e22c44d0dcdd7a057/d66adabe91803ef34a8b90613c81267b5ded1472 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20044).(CVE-2025-38212) In the Linux kernel, the following vulnerability has been resolved: media: cxusb: no longer judge rbuf when the write fails syzbot reported a uninit-value in cxusb_i2c_xfer. [1] Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw() succeeds and rlen is greater than 0, the read operation of usb_bulk_msg() will be executed to read rlen bytes of data from the dvb device into the rbuf. In this case, although rlen is 1, the write operation failed which resulted in the dvb read operation not being executed, and ultimately variable i was not initialized. [1] BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-38229) A vulnerability was found in Linux Kernel up to 6.16-rc2 (Operating System). It has been declared as problematic.The CWE definition for the vulnerability is CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.As an impact it is known to affect confidentiality.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 64773b3ea09235168a549a195cba43bb867c4a17/67abac27d806e8f9d4226ec1528540cf73af673a/92750bfe7b0d8dbcaf578c091a65eda1c5f9ad38/01f91d415a8375d85e0c7d3615cd4a168308bb7c/21da6d3561f373898349ca7167c9811c020da695/22f935bc86bdfbde04009f05eee191d220cd8c89/422e565b7889ebfd9c8705a3fc786642afe61fca/39dfc971e42d886e7df01371cd1bef505076d84c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20926).(CVE-2025-38320) A vulnerability was found in Linux Kernel up to 6.15.3 (Operating System). It has been declared as critical.The CWE definition for the vulnerability is CWE-119. The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch d064c68781c19f378af1ae741d9132d35d24b2bb/8690cd3258455bbae64f809e1d3ee0f043661c71/6805582abb720681dd1c87ff677f155dcf4e86c9/03a162933c4a03b9f1a84f7d8482903c7e1e11bb/83a692a9792aa86249d68a8ac0b9d55ecdd255fa/8e89c17dc8970c5f71a3a991f5724d4c8de42d8c/f78a786ad9a5443a29eef4dae60cde85b7375129/f914b52c379c12288b7623bb814d0508dbe7481d is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38346) An update for kernel is now available for openEuler-20.03-LTS-SP4/openEuler-22.03-LTS-SP3. 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-1872 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50224 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-58002 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-21855 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38108 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38212 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38229 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38320 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38346 https://nvd.nist.gov/vuln/detail/CVE-2022-50224 https://nvd.nist.gov/vuln/detail/CVE-2024-58002 https://nvd.nist.gov/vuln/detail/CVE-2025-21855 https://nvd.nist.gov/vuln/detail/CVE-2025-38108 https://nvd.nist.gov/vuln/detail/CVE-2025-38212 https://nvd.nist.gov/vuln/detail/CVE-2025-38229 https://nvd.nist.gov/vuln/detail/CVE-2025-38320 https://nvd.nist.gov/vuln/detail/CVE-2025-38346 openEuler-22.03-LTS-SP3 kernel-5.10.0-273.0.0.175.oe2203sp3.aarch64.rpm kernel-debuginfo-5.10.0-273.0.0.175.oe2203sp3.aarch64.rpm kernel-debugsource-5.10.0-273.0.0.175.oe2203sp3.aarch64.rpm kernel-devel-5.10.0-273.0.0.175.oe2203sp3.aarch64.rpm kernel-headers-5.10.0-273.0.0.175.oe2203sp3.aarch64.rpm kernel-source-5.10.0-273.0.0.175.oe2203sp3.aarch64.rpm kernel-tools-5.10.0-273.0.0.175.oe2203sp3.aarch64.rpm kernel-tools-debuginfo-5.10.0-273.0.0.175.oe2203sp3.aarch64.rpm kernel-tools-devel-5.10.0-273.0.0.175.oe2203sp3.aarch64.rpm perf-5.10.0-273.0.0.175.oe2203sp3.aarch64.rpm perf-debuginfo-5.10.0-273.0.0.175.oe2203sp3.aarch64.rpm python3-perf-5.10.0-273.0.0.175.oe2203sp3.aarch64.rpm python3-perf-debuginfo-5.10.0-273.0.0.175.oe2203sp3.aarch64.rpm kernel-5.10.0-273.0.0.175.oe2203sp3.src.rpm kernel-5.10.0-273.0.0.175.oe2203sp3.x86_64.rpm kernel-debuginfo-5.10.0-273.0.0.175.oe2203sp3.x86_64.rpm kernel-debugsource-5.10.0-273.0.0.175.oe2203sp3.x86_64.rpm kernel-devel-5.10.0-273.0.0.175.oe2203sp3.x86_64.rpm kernel-headers-5.10.0-273.0.0.175.oe2203sp3.x86_64.rpm kernel-source-5.10.0-273.0.0.175.oe2203sp3.x86_64.rpm kernel-tools-5.10.0-273.0.0.175.oe2203sp3.x86_64.rpm kernel-tools-debuginfo-5.10.0-273.0.0.175.oe2203sp3.x86_64.rpm kernel-tools-devel-5.10.0-273.0.0.175.oe2203sp3.x86_64.rpm perf-5.10.0-273.0.0.175.oe2203sp3.x86_64.rpm perf-debuginfo-5.10.0-273.0.0.175.oe2203sp3.x86_64.rpm python3-perf-5.10.0-273.0.0.175.oe2203sp3.x86_64.rpm python3-perf-debuginfo-5.10.0-273.0.0.175.oe2203sp3.x86_64.rpm In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Treat NX as a valid SPTE bit for NPT Treat the NX bit as valid when using NPT, as KVM will set the NX bit when the NX huge page mitigation is enabled (mindblowing) and trigger the WARN that fires on reserved SPTE bits being set. KVM has required NX support for SVM since commit b26a71a1a5b9 ("KVM: SVM: Refuse to load kvm_amd if NX support is not available") for exactly this reason, but apparently it never occurred to anyone to actually test NPT with the mitigation enabled. ------------[ cut here ]------------ spte = 0x800000018a600ee7, level = 2, rsvd bits = 0x800f0000001fe000 WARNING: CPU: 152 PID: 15966 at arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm] Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/27/2022 RIP: 0010:make_spte+0x327/0x340 [kvm] Call Trace: <TASK> tdp_mmu_map_handle_target_level+0xc3/0x230 [kvm] kvm_tdp_mmu_map+0x343/0x3b0 [kvm] direct_page_fault+0x1ae/0x2a0 [kvm] kvm_tdp_page_fault+0x7d/0x90 [kvm] kvm_mmu_page_fault+0xfb/0x2e0 [kvm] npf_interception+0x55/0x90 [kvm_amd] svm_invoke_exit_handler+0x31/0xf0 [kvm_amd] svm_handle_exit+0xf6/0x1d0 [kvm_amd] vcpu_enter_guest+0xb6d/0xee0 [kvm] ? kvm_pmu_trigger_event+0x6d/0x230 [kvm] vcpu_run+0x65/0x2c0 [kvm] kvm_arch_vcpu_ioctl_run+0x355/0x610 [kvm] kvm_vcpu_ioctl+0x551/0x610 [kvm] __se_sys_ioctl+0x77/0xc0 __x64_sys_ioctl+0x1d/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> ---[ end trace 0000000000000000 ]--- 2025-07-18 CVE-2022-50224 openEuler-22.03-LTS-SP3 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-07-18 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1872 In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Remove dangling pointers When an async control is written, we copy a pointer to the file handle that started the operation. That pointer will be used when the device is done. Which could be anytime in the future. If the user closes that file descriptor, its structure will be freed, and there will be one dangling pointer per pending async control, that the driver will try to use. Clean all the dangling pointers during release(). To avoid adding a performance penalty in the most common case (no async operation), a counter has been introduced with some logic to make sure that it is properly handled. 2025-07-18 CVE-2024-58002 openEuler-22.03-LTS-SP3 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-07-18 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1872 In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Don't reference skb after sending to VIOS Previously, after successfully flushing the xmit buffer to VIOS, the tx_bytes stat was incremented by the length of the skb. It is invalid to access the skb memory after sending the buffer to the VIOS because, at any point after sending, the VIOS can trigger an interrupt to free this memory. A race between reading skb->len and freeing the skb is possible (especially during LPM) and will result in use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic] Read of size 4 at addr c00000024eb48a70 by task hxecom/14495 <...> Call Trace: [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable) [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0 [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8 [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0 [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic] [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358 <...> Freed by task 0: kasan_save_stack+0x34/0x68 kasan_save_track+0x2c/0x50 kasan_save_free_info+0x64/0x108 __kasan_mempool_poison_object+0x148/0x2d4 napi_skb_cache_put+0x5c/0x194 net_tx_action+0x154/0x5b8 handle_softirqs+0x20c/0x60c do_softirq_own_stack+0x6c/0x88 <...> The buggy address belongs to the object at c00000024eb48a00 which belongs to the cache skbuff_head_cache of size 224 ================================================================== 2025-07-18 CVE-2025-21855 openEuler-22.03-LTS-SP3 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-07-18 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1872 A vulnerability classified as problematic was found in Linux Kernel up to 6.16-rc1 (Operating System).The CWE definition for the vulnerability is CWE-362. The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch 2790c4ec481be45a80948d059cd7c9a06bc37493/a1bf6a4e9264a685b0e642994031f9c5aad72414/110a47efcf23438ff8d31dbd9c854fae2a48bf98/f569984417a4e12c67366e69bdcb752970de921d/2a71924ca4af59ffc00f0444732b6cd54b153d0e/4b755305b2b0618e857fdadb499365b5f2e478d1/444ad445df5496a785705019268a8a84b84484bb/85a3e0ede38450ea3053b8c45d28cf55208409b8 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version. 2025-07-18 CVE-2025-38108 openEuler-22.03-LTS-SP3 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-07-18 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1872 A vulnerability was found in Linux Kernel up to 6.15.3 (Operating System). It has been rated as critical.Using CWE to declare the problem leads to CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.Impacted is confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch 5f1e1573bf103303944fd7225559de5d8297539c/b968ba8bfd9f90914957bbbd815413bf6a98eca7/74bc813d11c30e28fc5261dc877cca662ccfac68/78297d53d3878d43c1d627d20cd09f611fa4b91d/5180561afff8e0f029073c8c8117c95c6512d1f9/68c173ea138b66d7dd1fd980c9bc578a18e11884/b0b6bf90ce2699a574b3683e22c44d0dcdd7a057/d66adabe91803ef34a8b90613c81267b5ded1472 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20044). 2025-07-18 CVE-2025-38212 openEuler-22.03-LTS-SP3 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-07-18 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1872 In the Linux kernel, the following vulnerability has been resolved: media: cxusb: no longer judge rbuf when the write fails syzbot reported a uninit-value in cxusb_i2c_xfer. [1] Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw() succeeds and rlen is greater than 0, the read operation of usb_bulk_msg() will be executed to read rlen bytes of data from the dvb device into the rbuf. In this case, although rlen is 1, the write operation failed which resulted in the dvb read operation not being executed, and ultimately variable i was not initialized. [1] BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f 2025-07-18 CVE-2025-38229 openEuler-22.03-LTS-SP3 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-07-18 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1872 A vulnerability was found in Linux Kernel up to 6.16-rc2 (Operating System). It has been declared as problematic.The CWE definition for the vulnerability is CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.As an impact it is known to affect confidentiality.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 64773b3ea09235168a549a195cba43bb867c4a17/67abac27d806e8f9d4226ec1528540cf73af673a/92750bfe7b0d8dbcaf578c091a65eda1c5f9ad38/01f91d415a8375d85e0c7d3615cd4a168308bb7c/21da6d3561f373898349ca7167c9811c020da695/22f935bc86bdfbde04009f05eee191d220cd8c89/422e565b7889ebfd9c8705a3fc786642afe61fca/39dfc971e42d886e7df01371cd1bef505076d84c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20926). 2025-07-18 CVE-2025-38320 openEuler-22.03-LTS-SP3 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-07-18 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1872 A vulnerability was found in Linux Kernel up to 6.15.3 (Operating System). It has been declared as critical.The CWE definition for the vulnerability is CWE-119. The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch d064c68781c19f378af1ae741d9132d35d24b2bb/8690cd3258455bbae64f809e1d3ee0f043661c71/6805582abb720681dd1c87ff677f155dcf4e86c9/03a162933c4a03b9f1a84f7d8482903c7e1e11bb/83a692a9792aa86249d68a8ac0b9d55ecdd255fa/8e89c17dc8970c5f71a3a991f5724d4c8de42d8c/f78a786ad9a5443a29eef4dae60cde85b7375129/f914b52c379c12288b7623bb814d0508dbe7481d is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version. 2025-07-18 CVE-2025-38346 openEuler-22.03-LTS-SP3 Low 3.9 AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L kernel security update 2025-07-18 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1872