<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
	<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS-SP2</DocumentTitle>
	<DocumentType>Security Advisory</DocumentType>
	<DocumentPublisher Type="Vendor">
		<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
		<IssuingAuthority>openEuler security committee</IssuingAuthority>
	</DocumentPublisher>
	<DocumentTracking>
		<Identification>
			<ID>openEuler-SA-2025-2552</ID>
		</Identification>
		<Status>Final</Status>
		<Version>1.0</Version>
		<RevisionHistory>
			<Revision>
				<Number>1.0</Number>
				<Date>2025-10-31</Date>
				<Description>Initial</Description>
			</Revision>
		</RevisionHistory>
		<InitialReleaseDate>2025-10-31</InitialReleaseDate>
		<CurrentReleaseDate>2025-10-31</CurrentReleaseDate>
		<Generator>
			<Engine>openEuler SA Tool V1.0</Engine>
			<Date>2025-10-31</Date>
		</Generator>
	</DocumentTracking>
	<DocumentNotes>
		<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
		<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS-SP2</Note>
		<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.

Security Fix(es):

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

pds_core: Prevent possible adminq overflow/stuck condition

The pds_core&apos;s adminq is protected by the adminq_lock, which prevents
more than 1 command to be posted onto it at any one time. This makes it
so the client drivers cannot simultaneously post adminq commands.
However, the completions happen in a different context, which means
multiple adminq commands can be posted sequentially and all waiting
on completion.

On the FW side, the backing adminq request queue is only 16 entries
long and the retry mechanism and/or overflow/stuck prevention is
lacking. This can cause the adminq to get stuck, so commands are no
longer processed and completions are no longer sent by the FW.

As an initial fix, prevent more than 16 outstanding adminq commands so
there&apos;s no way to cause the adminq from getting stuck. This works
because the backing adminq request queue will never have more than 16
pending adminq commands, so it will never overflow. This is done by
reducing the adminq depth to 16.(CVE-2025-37987)

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

regulator: core: fix NULL dereference on unbind due to stale coupling data

Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can
lead to NULL pointer dereference when regulators are accessed post-unbind.

This can happen during runtime PM or other regulator operations that rely
on coupling metadata.

For example, on ridesx4, unbinding the &apos;reg-dummy&apos; platform device triggers
a panic in regulator_lock_recursive() due to stale coupling state.

Ensure n_coupled is set to 0 to prevent access to invalid pointers.(CVE-2025-38668)

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

drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().

When the nvif_vmm_type is invalid, we will return error directly
without freeing the args in nvif_vmm_ctor(), which leading a memory
leak. Fix it by setting the ret -EINVAL and goto done.(CVE-2025-39679)

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

serial: 8250: fix panic due to PSLVERR

When the PSLVERR_RESP_EN parameter is set to 1, the device generates
an error response if an attempt is made to read an empty RBR (Receive
Buffer Register) while the FIFO is enabled.

In serial8250_do_startup(), calling serial_port_out(port, UART_LCR,
UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes
dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter
function enables the FIFO via serial_out(p, UART_FCR, p-&gt;fcr).
Execution proceeds to the serial_port_in(port, UART_RX).
This satisfies the PSLVERR trigger condition.

When another CPU (e.g., using printk()) is accessing the UART (UART
is busy), the current CPU fails the check (value &amp; ~UART_LCR_SPAR) ==
(lcr &amp; ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter
dw8250_force_idle().

Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port-&gt;lock
to fix this issue.

Panic backtrace:
[    0.442336] Oops - unknown exception [#1]
[    0.442343] epc : dw8250_serial_in32+0x1e/0x4a
[    0.442351]  ra : serial8250_do_startup+0x2c8/0x88e
...
[    0.442416] console_on_rootfs+0x26/0x70(CVE-2025-39724)

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

HID: multitouch: fix slab out-of-bounds access in mt_report_fixup()

A malicious HID device can trigger a slab out-of-bounds during
mt_report_fixup() by passing in report descriptor smaller than
607 bytes. mt_report_fixup() attempts to patch byte offset 607
of the descriptor with 0x25 by first checking if byte offset
607 is 0x15 however it lacks bounds checks to verify if the
descriptor is big enough before conducting this check. Fix
this bug by ensuring the descriptor size is at least 608
bytes before accessing it.

Below is the KASAN splat after the out of bounds access happens:

[   13.671954] ==================================================================
[   13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110
[   13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10
[   13.673297]
[   13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3
[   13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04
[   13.673297] Call Trace:
[   13.673297]  &lt;TASK&gt;
[   13.673297]  dump_stack_lvl+0x5f/0x80
[   13.673297]  print_report+0xd1/0x660
[   13.673297]  kasan_report+0xe5/0x120
[   13.673297]  __asan_report_load1_noabort+0x18/0x20
[   13.673297]  mt_report_fixup+0x103/0x110
[   13.673297]  hid_open_report+0x1ef/0x810
[   13.673297]  mt_probe+0x422/0x960
[   13.673297]  hid_device_probe+0x2e2/0x6f0
[   13.673297]  really_probe+0x1c6/0x6b0
[   13.673297]  __driver_probe_device+0x24f/0x310
[   13.673297]  driver_probe_device+0x4e/0x220
[   13.673297]  __device_attach_driver+0x169/0x320
[   13.673297]  bus_for_each_drv+0x11d/0x1b0
[   13.673297]  __device_attach+0x1b8/0x3e0
[   13.673297]  device_initial_probe+0x12/0x20
[   13.673297]  bus_probe_device+0x13d/0x180
[   13.673297]  device_add+0xe3a/0x1670
[   13.673297]  hid_add_device+0x31d/0xa40
[...](CVE-2025-39806)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)

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

fbcon: fix integer overflow in fbcon_do_set_font

Fix integer overflow vulnerabilities in fbcon_do_set_font() where font
size calculations could overflow when handling user-controlled font
parameters.

The vulnerabilities occur when:
1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount
   multiplication with user-controlled values that can overflow.
2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow
3. This results in smaller allocations than expected, leading to buffer
   overflows during font data copying.

Add explicit overflow checking using check_mul_overflow() and
check_add_overflow() kernel helpers to safety validate all size
calculations before allocation.(CVE-2025-39967)

In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_syncThis fixes the following UFA in hci_acl_create_conn_sync where aconnection still pending is command submission (conn-&gt;state == BT_OPEN)maybe freed, also since this also can happen with the likes ofhci_le_create_conn_sync fix it as well:BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci3 hci_cmd_sync_workCall Trace: &lt;TASK&gt; dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 &lt;/TASK&gt;Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour---truncated---(CVE-2025-39982)

In the Linux kernel, the iMON driver has a race condition vulnerability. The issue stems from imon_disconnect() improperly releasing the usb_device reference without coordinating with active users of the device. Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx-&gt;users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage. This can lead to a use-after-free (UAF) of the usb_device pointer if vfd_write or other operations are still in progress after disconnect.(CVE-2025-39993)

In the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer &quot;buf&quot; without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)

In the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essiv_aead_crypt so thatit s also checked for decryption and in-place encryption.(CVE-2025-40019)</Note>
		<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS-SP2.

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.</Note>
		<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
		<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
	</DocumentNotes>
	<DocumentReferences>
		<Reference Type="Self">
			<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2552</URL>
		</Reference>
		<Reference Type="openEuler CVE">
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-37987</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38668</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39679</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39724</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39806</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39898</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39967</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39982</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39993</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39998</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40019</URL>
		</Reference>
		<Reference Type="Other">
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-37987</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-38668</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-39679</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-39724</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-39806</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-39898</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-39967</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-39982</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-39993</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-39998</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-40019</URL>
		</Reference>
	</DocumentReferences>
	<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
		<Branch Type="Product Name" Name="openEuler">
			<FullProductName ProductID="openEuler-24.03-LTS-SP2" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">openEuler-24.03-LTS-SP2</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="src">
			<FullProductName ProductID="kernel-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-6.6.0-114.0.0.120.oe2403sp2.src.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="aarch64">
			<FullProductName ProductID="bpftool-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">bpftool-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="bpftool-debuginfo-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">bpftool-debuginfo-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debuginfo-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-debuginfo-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debugsource-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-debugsource-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-devel-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-devel-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-extra-modules-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-extra-modules-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-headers-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-headers-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-source-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-source-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-tools-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-tools-debuginfo-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-devel-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-tools-devel-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="perf-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">perf-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="perf-debuginfo-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">perf-debuginfo-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">python3-perf-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-debuginfo-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">python3-perf-debuginfo-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="x86_64">
			<FullProductName ProductID="bpftool-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">bpftool-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="bpftool-debuginfo-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">bpftool-debuginfo-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debuginfo-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-debuginfo-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debugsource-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-debugsource-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-devel-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-devel-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-extra-modules-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-extra-modules-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-headers-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-headers-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-source-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-source-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-tools-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-tools-debuginfo-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-devel-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-tools-devel-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="perf-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">perf-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="perf-debuginfo-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">perf-debuginfo-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">python3-perf-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-debuginfo-6.6.0-114.0.0.120" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">python3-perf-debuginfo-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm</FullProductName>
		</Branch>
	</ProductTree>
	<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pds_core: Prevent possible adminq overflow/stuck condition

The pds_core&apos;s adminq is protected by the adminq_lock, which prevents
more than 1 command to be posted onto it at any one time. This makes it
so the client drivers cannot simultaneously post adminq commands.
However, the completions happen in a different context, which means
multiple adminq commands can be posted sequentially and all waiting
on completion.

On the FW side, the backing adminq request queue is only 16 entries
long and the retry mechanism and/or overflow/stuck prevention is
lacking. This can cause the adminq to get stuck, so commands are no
longer processed and completions are no longer sent by the FW.

As an initial fix, prevent more than 16 outstanding adminq commands so
there&apos;s no way to cause the adminq from getting stuck. This works
because the backing adminq request queue will never have more than 16
pending adminq commands, so it will never overflow. This is done by
reducing the adminq depth to 16.</Note>
		</Notes>
		<ReleaseDate>2025-10-31</ReleaseDate>
		<CVE>CVE-2025-37987</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP2</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Low</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>3.9</BaseScore>
				<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2025-10-31</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2552</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

regulator: core: fix NULL dereference on unbind due to stale coupling data

Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can
lead to NULL pointer dereference when regulators are accessed post-unbind.

This can happen during runtime PM or other regulator operations that rely
on coupling metadata.

For example, on ridesx4, unbinding the &apos;reg-dummy&apos; platform device triggers
a panic in regulator_lock_recursive() due to stale coupling state.

Ensure n_coupled is set to 0 to prevent access to invalid pointers.</Note>
		</Notes>
		<ReleaseDate>2025-10-31</ReleaseDate>
		<CVE>CVE-2025-38668</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP2</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>4.4</BaseScore>
				<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2025-10-31</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2552</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().

When the nvif_vmm_type is invalid, we will return error directly
without freeing the args in nvif_vmm_ctor(), which leading a memory
leak. Fix it by setting the ret -EINVAL and goto done.</Note>
		</Notes>
		<ReleaseDate>2025-10-31</ReleaseDate>
		<CVE>CVE-2025-39679</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP2</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2025-10-31</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2552</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="4" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

serial: 8250: fix panic due to PSLVERR

When the PSLVERR_RESP_EN parameter is set to 1, the device generates
an error response if an attempt is made to read an empty RBR (Receive
Buffer Register) while the FIFO is enabled.

In serial8250_do_startup(), calling serial_port_out(port, UART_LCR,
UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes
dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter
function enables the FIFO via serial_out(p, UART_FCR, p-&gt;fcr).
Execution proceeds to the serial_port_in(port, UART_RX).
This satisfies the PSLVERR trigger condition.

When another CPU (e.g., using printk()) is accessing the UART (UART
is busy), the current CPU fails the check (value &amp; ~UART_LCR_SPAR) ==
(lcr &amp; ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter
dw8250_force_idle().

Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port-&gt;lock
to fix this issue.

Panic backtrace:
[    0.442336] Oops - unknown exception [#1]
[    0.442343] epc : dw8250_serial_in32+0x1e/0x4a
[    0.442351]  ra : serial8250_do_startup+0x2c8/0x88e
...
[    0.442416] console_on_rootfs+0x26/0x70</Note>
		</Notes>
		<ReleaseDate>2025-10-31</ReleaseDate>
		<CVE>CVE-2025-39724</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP2</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>4.4</BaseScore>
				<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2025-10-31</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2552</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="5" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: multitouch: fix slab out-of-bounds access in mt_report_fixup()

A malicious HID device can trigger a slab out-of-bounds during
mt_report_fixup() by passing in report descriptor smaller than
607 bytes. mt_report_fixup() attempts to patch byte offset 607
of the descriptor with 0x25 by first checking if byte offset
607 is 0x15 however it lacks bounds checks to verify if the
descriptor is big enough before conducting this check. Fix
this bug by ensuring the descriptor size is at least 608
bytes before accessing it.

Below is the KASAN splat after the out of bounds access happens:

[   13.671954] ==================================================================
[   13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110
[   13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10
[   13.673297]
[   13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3
[   13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04
[   13.673297] Call Trace:
[   13.673297]  &lt;TASK&gt;
[   13.673297]  dump_stack_lvl+0x5f/0x80
[   13.673297]  print_report+0xd1/0x660
[   13.673297]  kasan_report+0xe5/0x120
[   13.673297]  __asan_report_load1_noabort+0x18/0x20
[   13.673297]  mt_report_fixup+0x103/0x110
[   13.673297]  hid_open_report+0x1ef/0x810
[   13.673297]  mt_probe+0x422/0x960
[   13.673297]  hid_device_probe+0x2e2/0x6f0
[   13.673297]  really_probe+0x1c6/0x6b0
[   13.673297]  __driver_probe_device+0x24f/0x310
[   13.673297]  driver_probe_device+0x4e/0x220
[   13.673297]  __device_attach_driver+0x169/0x320
[   13.673297]  bus_for_each_drv+0x11d/0x1b0
[   13.673297]  __device_attach+0x1b8/0x3e0
[   13.673297]  device_initial_probe+0x12/0x20
[   13.673297]  bus_probe_device+0x13d/0x180
[   13.673297]  device_add+0xe3a/0x1670
[   13.673297]  hid_add_device+0x31d/0xa40
[...]</Note>
		</Notes>
		<ReleaseDate>2025-10-31</ReleaseDate>
		<CVE>CVE-2025-39806</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP2</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>High</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>7.0</BaseScore>
				<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2025-10-31</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2552</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="6" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
		</Notes>
		<ReleaseDate>2025-10-31</ReleaseDate>
		<CVE>CVE-2025-39898</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP2</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>High</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>7.0</BaseScore>
				<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2025-10-31</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2552</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="7" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fbcon: fix integer overflow in fbcon_do_set_font

Fix integer overflow vulnerabilities in fbcon_do_set_font() where font
size calculations could overflow when handling user-controlled font
parameters.

The vulnerabilities occur when:
1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount
   multiplication with user-controlled values that can overflow.
2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow
3. This results in smaller allocations than expected, leading to buffer
   overflows during font data copying.

Add explicit overflow checking using check_mul_overflow() and
check_add_overflow() kernel helpers to safety validate all size
calculations before allocation.</Note>
		</Notes>
		<ReleaseDate>2025-10-31</ReleaseDate>
		<CVE>CVE-2025-39967</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP2</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2025-10-31</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2552</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="8" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_syncThis fixes the following UFA in hci_acl_create_conn_sync where aconnection still pending is command submission (conn-&gt;state == BT_OPEN)maybe freed, also since this also can happen with the likes ofhci_le_create_conn_sync fix it as well:BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci3 hci_cmd_sync_workCall Trace: &lt;TASK&gt; dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 &lt;/TASK&gt;Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour---truncated---</Note>
		</Notes>
		<ReleaseDate>2025-10-31</ReleaseDate>
		<CVE>CVE-2025-39982</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP2</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>High</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>7.0</BaseScore>
				<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2025-10-31</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2552</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="9" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the iMON driver has a race condition vulnerability. The issue stems from imon_disconnect() improperly releasing the usb_device reference without coordinating with active users of the device. Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx-&gt;users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage. This can lead to a use-after-free (UAF) of the usb_device pointer if vfd_write or other operations are still in progress after disconnect.</Note>
		</Notes>
		<ReleaseDate>2025-10-31</ReleaseDate>
		<CVE>CVE-2025-39993</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP2</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>High</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>7.0</BaseScore>
				<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2025-10-31</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2552</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="10" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer &quot;buf&quot; without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.</Note>
		</Notes>
		<ReleaseDate>2025-10-31</ReleaseDate>
		<CVE>CVE-2025-39998</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP2</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>High</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>7.0</BaseScore>
				<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2025-10-31</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2552</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="11" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essiv_aead_crypt so thatit s also checked for decryption and in-place encryption.</Note>
		</Notes>
		<ReleaseDate>2025-10-31</ReleaseDate>
		<CVE>CVE-2025-40019</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS-SP2</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>6.1</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2025-10-31</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2552</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
</cvrfdoc>