<?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-2056</ID>
		</Identification>
		<Status>Final</Status>
		<Version>1.0</Version>
		<RevisionHistory>
			<Revision>
				<Number>1.0</Number>
				<Date>2025-08-22</Date>
				<Description>Initial</Description>
			</Revision>
		</RevisionHistory>
		<InitialReleaseDate>2025-08-22</InitialReleaseDate>
		<CurrentReleaseDate>2025-08-22</CurrentReleaseDate>
		<Generator>
			<Engine>openEuler SA Tool V1.0</Engine>
			<Date>2025-08-22</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:

drm/vkms: Fix use after free and double free on init error

If the driver initialization fails, the vkms_exit() function might
access an uninitialized or freed default_config pointer and it might
double free it.

Fix both possible errors by initializing default_config only when the
driver initialization succeeded.(CVE-2025-22097)

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

wifi: at76c50x: fix use after free access in at76_disconnect

The memory pointed to by priv is freed at the end of at76_delete_device
function (using ieee80211_free_hw). But the code then accesses the udev
field of the freed object to put the USB device. This may also lead to a
memory leak of the usb device. Fix this by using udev from interface.(CVE-2025-37796)

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

codel: remove sch-&gt;q.qlen check before qdisc_tree_reduce_backlog()

After making all -&gt;qlen_notify() callbacks idempotent, now it is safe to
remove the check of qlen!=0 from both fq_codel_dequeue() and
codel_qdisc_dequeue().(CVE-2025-37798)

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

net_sched: qfq: Fix double list add in class with netem as child qdisc

As described in Gerrard&apos;s report [1], there are use cases where a netem
child qdisc will make the parent qdisc&apos;s enqueue callback reentrant.
In the case of qfq, there won&apos;t be a UAF, but the code will add the same
classifier to the list twice, which will cause memory corruption.

This patch checks whether the class was already added to the agg-&gt;active
list (cl_is_active) before doing the addition to cater for the reentrant
case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37913)

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

net_sched: drr: Fix double list add in class with netem as child qdisc

As described in Gerrard&apos;s report [1], there are use cases where a netem
child qdisc will make the parent qdisc&apos;s enqueue callback reentrant.
In the case of drr, there won&apos;t be a UAF, but the code will add the same
classifier to the list twice, which will cause memory corruption.

In addition to checking for qlen being zero, this patch checks whether the
class was already added to the active_list (cl_is_active) before adding
to the list to cover for the reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37915)

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

RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction

The commit 59c68ac31e15 (&quot;iw_cm: free cm_id resources on the last
deref&quot;) simplified cm_id resource management by freeing cm_id once all
references to the cm_id were removed. The references are removed either
upon completion of iw_cm event handlers or when the application destroys
the cm_id. This commit introduced the use-after-free condition where
cm_id_private object could still be in use by event handler works during
the destruction of cm_id. The commit aee2424246f9 (&quot;RDMA/iwcm: Fix a
use-after-free related to destroying CM IDs&quot;) addressed this use-after-
free by flushing all pending works at the cm_id destruction.

However, still another use-after-free possibility remained. It happens
with the work objects allocated for each cm_id_priv within
alloc_work_entries() during cm_id creation, and subsequently freed in
dealloc_work_entries() once all references to the cm_id are removed.
If the cm_id&apos;s last reference is decremented in the event handler work,
the work object for the work itself gets removed, and causes the use-
after-free BUG below:

  BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250
  Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091

  CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary)
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
  Workqueue:  0x0 (iw_cm_wq)
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x6a/0x90
   print_report+0x174/0x554
   ? __virt_addr_valid+0x208/0x430
   ? __pwq_activate_work+0x1ff/0x250
   kasan_report+0xae/0x170
   ? __pwq_activate_work+0x1ff/0x250
   __pwq_activate_work+0x1ff/0x250
   pwq_dec_nr_in_flight+0x8c5/0xfb0
   process_one_work+0xc11/0x1460
   ? __pfx_process_one_work+0x10/0x10
   ? assign_work+0x16c/0x240
   worker_thread+0x5ef/0xfd0
   ? __pfx_worker_thread+0x10/0x10
   kthread+0x3b0/0x770
   ? __pfx_kthread+0x10/0x10
   ? rcu_is_watching+0x11/0xb0
   ? _raw_spin_unlock_irq+0x24/0x50
   ? rcu_is_watching+0x11/0xb0
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x70
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1a/0x30
   &lt;/TASK&gt;

  Allocated by task 147416:
   kasan_save_stack+0x2c/0x50
   kasan_save_track+0x10/0x30
   __kasan_kmalloc+0xa6/0xb0
   alloc_work_entries+0xa9/0x260 [iw_cm]
   iw_cm_connect+0x23/0x4a0 [iw_cm]
   rdma_connect_locked+0xbfd/0x1920 [rdma_cm]
   nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma]
   cma_cm_event_handler+0xae/0x320 [rdma_cm]
   cma_work_handler+0x106/0x1b0 [rdma_cm]
   process_one_work+0x84f/0x1460
   worker_thread+0x5ef/0xfd0
   kthread+0x3b0/0x770
   ret_from_fork+0x30/0x70
   ret_from_fork_asm+0x1a/0x30

  Freed by task 147091:
   kasan_save_stack+0x2c/0x50
   kasan_save_track+0x10/0x30
   kasan_save_free_info+0x37/0x60
   __kasan_slab_free+0x4b/0x70
   kfree+0x13a/0x4b0
   dealloc_work_entries+0x125/0x1f0 [iw_cm]
   iwcm_deref_id+0x6f/0xa0 [iw_cm]
   cm_work_handler+0x136/0x1ba0 [iw_cm]
   process_one_work+0x84f/0x1460
   worker_thread+0x5ef/0xfd0
   kthread+0x3b0/0x770
   ret_from_fork+0x30/0x70
   ret_from_fork_asm+0x1a/0x30

  Last potentially related work creation:
   kasan_save_stack+0x2c/0x50
   kasan_record_aux_stack+0xa3/0xb0
   __queue_work+0x2ff/0x1390
   queue_work_on+0x67/0xc0
   cm_event_handler+0x46a/0x820 [iw_cm]
   siw_cm_upcall+0x330/0x650 [siw]
   siw_cm_work_handler+0x6b9/0x2b20 [siw]
   process_one_work+0x84f/0x1460
   worker_thread+0x5ef/0xfd0
   kthread+0x3b0/0x770
   ret_from_fork+0x30/0x70
   ret_from_fork_asm+0x1a/0x30

This BUG is reproducible by repeating the blktests test case nvme/061
for the rdma transport and the siw driver.

To avoid the use-after-free of cm_id_private work objects, ensure that
the last reference to the cm_id is decremented not in the event handler
works, but in the cm_id destruction context. For that purpose, mo
---truncated---(CVE-2025-38211)

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

atm: clip: prevent NULL deref in clip_push()

Blamed commit missed that vcc_destroy_socket() calls
clip_push() with a NULL skb.

If clip_devs is NULL, clip_push() then crashes when reading
skb-&gt;truesize.(CVE-2025-38251)

A vulnerability was found in Linux Kernel up to 6.16-rc4 (Operating System) and classified as problematic.Using CWE to declare the problem leads to CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.Impacted is confidentiality.Upgrading to version 5.15.189, 6.1.144, 6.6.97, 6.12.37, 6.15.6 or 6.16-rc5 eliminates this vulnerability. Applying the patch 982beb7582c193544eb9c6083937ec5ac1c9d651/6aca3dad2145e864dfe4d1060f45eb1bac75dd58/80b971be4c37a4d23a7f1abc5ff33dc7733d649b/bc68bc3563344ccdc57d1961457cdeecab8f81ef/11f2d0e8be2b5e784ac45fa3da226492c3e506d8/315dbdd7cdf6aa533829774caaf4d25f1fd20e73 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-38375)

A vulnerability was found in Linux Kernel up to 6.1.146/6.6.99/6.12.39/6.15.7 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.147, 6.6.100, 6.12.40 or 6.15.8 eliminates this vulnerability. Applying the patch ac3a8147bb24314fb3e84986590148e79f9872ec/c4f16f6b071a74ac7eefe5c28985285cbbe2cd96/b97be7ee8a1cd96b89817cbd64a9f5cc16c17d08/6d63901dcd592a1e3f71d7c6d78f9be5e8d7eef0/a0075accbf0d76c2dad1ad3993d2e944505d99a0 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-38473)

A vulnerability, which was classified as problematic, was found in Linux Kernel up to 6.1.146/6.6.99/6.12.39/6.15.7 (Operating System).CWE is classifying the issue as CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.147, 6.6.100, 6.12.40 or 6.15.8 eliminates this vulnerability. Applying the patch d3ed1d84a84538a39b3eb2055d6a97a936c108f2/fcda39a9c5b834346088c14b1374336b079466c1/a262370f385e53ff7470efdcdaf40468e5756717/a47d9d9895bad9ce0e840a39836f19ca0b2a343a/4f15ee98304b96e164ff2340e1dfd6181c3f42aa 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-38495)

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

bpf: Reject %p% format string in bprintf-like helpers

static const char fmt[] = &quot;%p%&quot;;
    bpf_trace_printk(fmt, sizeof(fmt));

The above BPF program isn&apos;t rejected and causes a kernel warning at
runtime:

    Please remove unsupported %\x00 in format string
    WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0

This happens because bpf_bprintf_prepare skips over the second %,
detected as punctuation, while processing %p. This patch fixes it by
not skipping over punctuation. %\x00 is then processed in the next
iteration and rejected.(CVE-2025-38528)</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-2056</URL>
		</Reference>
		<Reference Type="openEuler CVE">
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-22097</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-37796</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-37798</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-37913</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-37915</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38211</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38251</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38375</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38473</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38495</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38528</URL>
		</Reference>
		<Reference Type="Other">
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-22097</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-37796</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-37798</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-37913</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-37915</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-38211</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-38251</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-38375</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-38473</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-38495</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-38528</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="aarch64">
			<FullProductName ProductID="bpftool-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">bpftool-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="bpftool-debuginfo-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">bpftool-debuginfo-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debuginfo-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-debuginfo-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debugsource-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-debugsource-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-devel-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-devel-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-extra-modules-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-extra-modules-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-headers-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-headers-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-source-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-source-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-tools-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-tools-debuginfo-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-devel-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-tools-devel-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="perf-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">perf-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="perf-debuginfo-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">perf-debuginfo-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">python3-perf-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-debuginfo-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">python3-perf-debuginfo-6.6.0-106.0.0.112.oe2403sp2.aarch64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="x86_64">
			<FullProductName ProductID="bpftool-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">bpftool-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="bpftool-debuginfo-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">bpftool-debuginfo-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debuginfo-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-debuginfo-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debugsource-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-debugsource-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-devel-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-devel-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-extra-modules-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-extra-modules-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-headers-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-headers-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-source-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-source-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-tools-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-tools-debuginfo-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-devel-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-tools-devel-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="perf-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">perf-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="perf-debuginfo-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">perf-debuginfo-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">python3-perf-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-debuginfo-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">python3-perf-debuginfo-6.6.0-106.0.0.112.oe2403sp2.x86_64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="src">
			<FullProductName ProductID="kernel-6.6.0-106.0.0.112" CPE="cpe:/a:openEuler:openEuler:24.03-LTS-SP2">kernel-6.6.0-106.0.0.112.oe2403sp2.src.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:

drm/vkms: Fix use after free and double free on init error

If the driver initialization fails, the vkms_exit() function might
access an uninitialized or freed default_config pointer and it might
double free it.

Fix both possible errors by initializing default_config only when the
driver initialization succeeded.</Note>
		</Notes>
		<ReleaseDate>2025-08-22</ReleaseDate>
		<CVE>CVE-2025-22097</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.8</BaseScore>
				<Vector>AV:L/AC:L/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-08-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2056</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:

wifi: at76c50x: fix use after free access in at76_disconnect

The memory pointed to by priv is freed at the end of at76_delete_device
function (using ieee80211_free_hw). But the code then accesses the udev
field of the freed object to put the USB device. This may also lead to a
memory leak of the usb device. Fix this by using udev from interface.</Note>
		</Notes>
		<ReleaseDate>2025-08-22</ReleaseDate>
		<CVE>CVE-2025-37796</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>8.0</BaseScore>
				<Vector>AV:A/AC:L/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-08-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2056</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:

codel: remove sch-&gt;q.qlen check before qdisc_tree_reduce_backlog()

After making all -&gt;qlen_notify() callbacks idempotent, now it is safe to
remove the check of qlen!=0 from both fq_codel_dequeue() and
codel_qdisc_dequeue().</Note>
		</Notes>
		<ReleaseDate>2025-08-22</ReleaseDate>
		<CVE>CVE-2025-37798</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.8</BaseScore>
				<Vector>AV:L/AC:L/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-08-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2056</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:

net_sched: qfq: Fix double list add in class with netem as child qdisc

As described in Gerrard&apos;s report [1], there are use cases where a netem
child qdisc will make the parent qdisc&apos;s enqueue callback reentrant.
In the case of qfq, there won&apos;t be a UAF, but the code will add the same
classifier to the list twice, which will cause memory corruption.

This patch checks whether the class was already added to the agg-&gt;active
list (cl_is_active) before doing the addition to cater for the reentrant
case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/</Note>
		</Notes>
		<ReleaseDate>2025-08-22</ReleaseDate>
		<CVE>CVE-2025-37913</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>8.0</BaseScore>
				<Vector>AV:A/AC:L/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-08-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2056</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:

net_sched: drr: Fix double list add in class with netem as child qdisc

As described in Gerrard&apos;s report [1], there are use cases where a netem
child qdisc will make the parent qdisc&apos;s enqueue callback reentrant.
In the case of drr, there won&apos;t be a UAF, but the code will add the same
classifier to the list twice, which will cause memory corruption.

In addition to checking for qlen being zero, this patch checks whether the
class was already added to the active_list (cl_is_active) before adding
to the list to cover for the reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/</Note>
		</Notes>
		<ReleaseDate>2025-08-22</ReleaseDate>
		<CVE>CVE-2025-37915</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-08-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2056</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">In the Linux kernel, the following vulnerability has been resolved:

RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction

The commit 59c68ac31e15 (&quot;iw_cm: free cm_id resources on the last
deref&quot;) simplified cm_id resource management by freeing cm_id once all
references to the cm_id were removed. The references are removed either
upon completion of iw_cm event handlers or when the application destroys
the cm_id. This commit introduced the use-after-free condition where
cm_id_private object could still be in use by event handler works during
the destruction of cm_id. The commit aee2424246f9 (&quot;RDMA/iwcm: Fix a
use-after-free related to destroying CM IDs&quot;) addressed this use-after-
free by flushing all pending works at the cm_id destruction.

However, still another use-after-free possibility remained. It happens
with the work objects allocated for each cm_id_priv within
alloc_work_entries() during cm_id creation, and subsequently freed in
dealloc_work_entries() once all references to the cm_id are removed.
If the cm_id&apos;s last reference is decremented in the event handler work,
the work object for the work itself gets removed, and causes the use-
after-free BUG below:

  BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250
  Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091

  CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary)
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
  Workqueue:  0x0 (iw_cm_wq)
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x6a/0x90
   print_report+0x174/0x554
   ? __virt_addr_valid+0x208/0x430
   ? __pwq_activate_work+0x1ff/0x250
   kasan_report+0xae/0x170
   ? __pwq_activate_work+0x1ff/0x250
   __pwq_activate_work+0x1ff/0x250
   pwq_dec_nr_in_flight+0x8c5/0xfb0
   process_one_work+0xc11/0x1460
   ? __pfx_process_one_work+0x10/0x10
   ? assign_work+0x16c/0x240
   worker_thread+0x5ef/0xfd0
   ? __pfx_worker_thread+0x10/0x10
   kthread+0x3b0/0x770
   ? __pfx_kthread+0x10/0x10
   ? rcu_is_watching+0x11/0xb0
   ? _raw_spin_unlock_irq+0x24/0x50
   ? rcu_is_watching+0x11/0xb0
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x70
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1a/0x30
   &lt;/TASK&gt;

  Allocated by task 147416:
   kasan_save_stack+0x2c/0x50
   kasan_save_track+0x10/0x30
   __kasan_kmalloc+0xa6/0xb0
   alloc_work_entries+0xa9/0x260 [iw_cm]
   iw_cm_connect+0x23/0x4a0 [iw_cm]
   rdma_connect_locked+0xbfd/0x1920 [rdma_cm]
   nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma]
   cma_cm_event_handler+0xae/0x320 [rdma_cm]
   cma_work_handler+0x106/0x1b0 [rdma_cm]
   process_one_work+0x84f/0x1460
   worker_thread+0x5ef/0xfd0
   kthread+0x3b0/0x770
   ret_from_fork+0x30/0x70
   ret_from_fork_asm+0x1a/0x30

  Freed by task 147091:
   kasan_save_stack+0x2c/0x50
   kasan_save_track+0x10/0x30
   kasan_save_free_info+0x37/0x60
   __kasan_slab_free+0x4b/0x70
   kfree+0x13a/0x4b0
   dealloc_work_entries+0x125/0x1f0 [iw_cm]
   iwcm_deref_id+0x6f/0xa0 [iw_cm]
   cm_work_handler+0x136/0x1ba0 [iw_cm]
   process_one_work+0x84f/0x1460
   worker_thread+0x5ef/0xfd0
   kthread+0x3b0/0x770
   ret_from_fork+0x30/0x70
   ret_from_fork_asm+0x1a/0x30

  Last potentially related work creation:
   kasan_save_stack+0x2c/0x50
   kasan_record_aux_stack+0xa3/0xb0
   __queue_work+0x2ff/0x1390
   queue_work_on+0x67/0xc0
   cm_event_handler+0x46a/0x820 [iw_cm]
   siw_cm_upcall+0x330/0x650 [siw]
   siw_cm_work_handler+0x6b9/0x2b20 [siw]
   process_one_work+0x84f/0x1460
   worker_thread+0x5ef/0xfd0
   kthread+0x3b0/0x770
   ret_from_fork+0x30/0x70
   ret_from_fork_asm+0x1a/0x30

This BUG is reproducible by repeating the blktests test case nvme/061
for the rdma transport and the siw driver.

To avoid the use-after-free of cm_id_private work objects, ensure that
the last reference to the cm_id is decremented not in the event handler
works, but in the cm_id destruction context. For that purpose, mo
---truncated---</Note>
		</Notes>
		<ReleaseDate>2025-08-22</ReleaseDate>
		<CVE>CVE-2025-38211</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:L/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2025-08-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2056</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:

atm: clip: prevent NULL deref in clip_push()

Blamed commit missed that vcc_destroy_socket() calls
clip_push() with a NULL skb.

If clip_devs is NULL, clip_push() then crashes when reading
skb-&gt;truesize.</Note>
		</Notes>
		<ReleaseDate>2025-08-22</ReleaseDate>
		<CVE>CVE-2025-38251</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.7</BaseScore>
				<Vector>AV:A/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-08-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2056</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">A vulnerability was found in Linux Kernel up to 6.16-rc4 (Operating System) and classified as problematic.Using CWE to declare the problem leads to CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.Impacted is confidentiality.Upgrading to version 5.15.189, 6.1.144, 6.6.97, 6.12.37, 6.15.6 or 6.16-rc5 eliminates this vulnerability. Applying the patch 982beb7582c193544eb9c6083937ec5ac1c9d651/6aca3dad2145e864dfe4d1060f45eb1bac75dd58/80b971be4c37a4d23a7f1abc5ff33dc7733d649b/bc68bc3563344ccdc57d1961457cdeecab8f81ef/11f2d0e8be2b5e784ac45fa3da226492c3e506d8/315dbdd7cdf6aa533829774caaf4d25f1fd20e73 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.</Note>
		</Notes>
		<ReleaseDate>2025-08-22</ReleaseDate>
		<CVE>CVE-2025-38375</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:L/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2025-08-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2056</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">A vulnerability was found in Linux Kernel up to 6.1.146/6.6.99/6.12.39/6.15.7 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.147, 6.6.100, 6.12.40 or 6.15.8 eliminates this vulnerability. Applying the patch ac3a8147bb24314fb3e84986590148e79f9872ec/c4f16f6b071a74ac7eefe5c28985285cbbe2cd96/b97be7ee8a1cd96b89817cbd64a9f5cc16c17d08/6d63901dcd592a1e3f71d7c6d78f9be5e8d7eef0/a0075accbf0d76c2dad1ad3993d2e944505d99a0 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.</Note>
		</Notes>
		<ReleaseDate>2025-08-22</ReleaseDate>
		<CVE>CVE-2025-38473</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-08-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2056</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">A vulnerability, which was classified as problematic, was found in Linux Kernel up to 6.1.146/6.6.99/6.12.39/6.15.7 (Operating System).CWE is classifying the issue as CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.147, 6.6.100, 6.12.40 or 6.15.8 eliminates this vulnerability. Applying the patch d3ed1d84a84538a39b3eb2055d6a97a936c108f2/fcda39a9c5b834346088c14b1374336b079466c1/a262370f385e53ff7470efdcdaf40468e5756717/a47d9d9895bad9ce0e840a39836f19ca0b2a343a/4f15ee98304b96e164ff2340e1dfd6181c3f42aa 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.</Note>
		</Notes>
		<ReleaseDate>2025-08-22</ReleaseDate>
		<CVE>CVE-2025-38495</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.8</BaseScore>
				<Vector>AV:L/AC:L/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-08-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2056</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:

bpf: Reject %p% format string in bprintf-like helpers

static const char fmt[] = &quot;%p%&quot;;
    bpf_trace_printk(fmt, sizeof(fmt));

The above BPF program isn&apos;t rejected and causes a kernel warning at
runtime:

    Please remove unsupported %\x00 in format string
    WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0

This happens because bpf_bprintf_prepare skips over the second %,
detected as punctuation, while processing %p. This patch fixes it by
not skipping over punctuation. %\x00 is then processed in the next
iteration and rejected.</Note>
		</Notes>
		<ReleaseDate>2025-08-22</ReleaseDate>
		<CVE>CVE-2025-38528</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-08-22</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2056</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
</cvrfdoc>