<?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-22.03-LTS-SP4</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-2470</ID>
		</Identification>
		<Status>Final</Status>
		<Version>1.0</Version>
		<RevisionHistory>
			<Revision>
				<Number>1.0</Number>
				<Date>2025-10-17</Date>
				<Description>Initial</Description>
			</Revision>
		</RevisionHistory>
		<InitialReleaseDate>2025-10-17</InitialReleaseDate>
		<CurrentReleaseDate>2025-10-17</CurrentReleaseDate>
		<Generator>
			<Engine>openEuler SA Tool V1.0</Engine>
			<Date>2025-10-17</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-22.03-LTS-SP4</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:

NFSD: Protect against send buffer overflow in NFSv2 READ

Since before the git era, NFSD has conserved the number of pages
held by each nfsd thread by combining the RPC receive and send
buffers into a single array of pages. This works because there are
no cases where an operation needs a large RPC Call message and a
large RPC Reply at the same time.

Once an RPC Call has been received, svc_process() updates
svc_rqst::rq_res to describe the part of rq_pages that can be
used for constructing the Reply. This means that the send buffer
(rq_res) shrinks when the received RPC record containing the RPC
Call is large.

A client can force this shrinkage on TCP by sending a correctly-
formed RPC Call header contained in an RPC record that is
excessively large. The full maximum payload size cannot be
constructed in that case.(CVE-2022-50410)

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

tracing: Limit access to parser-&gt;buffer when trace_get_user failed

When the length of the string written to set_ftrace_filter exceeds
FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:

BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0
Read of size 1 at addr ffff0000d00bd5ba by task ash/165

CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty
Hardware name: linux,dummy-virt (DT)
Call trace:
 show_stack+0x34/0x50 (C)
 dump_stack_lvl+0xa0/0x158
 print_address_description.constprop.0+0x88/0x398
 print_report+0xb0/0x280
 kasan_report+0xa4/0xf0
 __asan_report_load1_noabort+0x20/0x30
 strsep+0x18c/0x1b0
 ftrace_process_regex.isra.0+0x100/0x2d8
 ftrace_regex_release+0x484/0x618
 __fput+0x364/0xa58
 ____fput+0x28/0x40
 task_work_run+0x154/0x278
 do_notify_resume+0x1f0/0x220
 el0_svc+0xec/0xf0
 el0t_64_sync_handler+0xa0/0xe8
 el0t_64_sync+0x1ac/0x1b0

The reason is that trace_get_user will fail when processing a string
longer than FTRACE_BUFF_MAX, but not set the end of parser-&gt;buffer to 0.
Then an OOB access will be triggered in ftrace_regex_release-&gt;
ftrace_process_regex-&gt;strsep-&gt;strpbrk. We can solve this problem by
limiting access to parser-&gt;buffer when trace_get_user failed.(CVE-2025-39683)

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

vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects

When the &quot;proxy&quot; option is enabled on a VXLAN device, the device will
suppress ARP requests and IPv6 Neighbor Solicitation messages if it is
able to reply on behalf of the remote host. That is, if a matching and
valid neighbor entry is configured on the VXLAN device whose MAC address
is not behind the &quot;any&quot; remote (0.0.0.0 / ::).

The code currently assumes that the FDB entry for the neighbor&apos;s MAC
address points to a valid remote destination, but this is incorrect if
the entry is associated with an FDB nexthop group. This can result in a
NPD [1][3] which can be reproduced using [2][4].

Fix by checking that the remote destination exists before dereferencing
it.

[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
RIP: 0010:vxlan_xmit+0xb58/0x15f0
[...]
Call Trace:
 &lt;TASK&gt;
 dev_hard_start_xmit+0x5d/0x1c0
 __dev_queue_xmit+0x246/0xfd0
 packet_sendmsg+0x113a/0x1850
 __sock_sendmsg+0x38/0x70
 __sys_sendto+0x126/0x180
 __x64_sys_sendto+0x24/0x30
 do_syscall_64+0xa4/0x260
 entry_SYSCALL_64_after_hwframe+0x4b/0x53

[2]
 #!/bin/bash

 ip address add 192.0.2.1/32 dev lo

 ip nexthop add id 1 via 192.0.2.2 fdb
 ip nexthop add id 10 group 1 fdb

 ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy

 ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0

 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10

 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3

[3]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014
RIP: 0010:vxlan_xmit+0x803/0x1600
[...]
Call Trace:
 &lt;TASK&gt;
 dev_hard_start_xmit+0x5d/0x1c0
 __dev_queue_xmit+0x246/0xfd0
 ip6_finish_output2+0x210/0x6c0
 ip6_finish_output+0x1af/0x2b0
 ip6_mr_output+0x92/0x3e0
 ip6_send_skb+0x30/0x90
 rawv6_sendmsg+0xe6e/0x12e0
 __sock_sendmsg+0x38/0x70
 __sys_sendto+0x126/0x180
 __x64_sys_sendto+0x24/0x30
 do_syscall_64+0xa4/0x260
 entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7f383422ec77

[4]
 #!/bin/bash

 ip address add 2001:db8:1::1/128 dev lo

 ip nexthop add id 1 via 2001:db8:1::1 fdb
 ip nexthop add id 10 group 1 fdb

 ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy

 ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0

 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10

 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)</Note>
		<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP4.

openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</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-2470</URL>
		</Reference>
		<Reference Type="openEuler CVE">
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50410</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39683</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39850</URL>
		</Reference>
		<Reference Type="Other">
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-50410</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-39683</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2025-39850</URL>
		</Reference>
	</DocumentReferences>
	<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
		<Branch Type="Product Name" Name="openEuler">
			<FullProductName ProductID="openEuler-22.03-LTS-SP4" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">openEuler-22.03-LTS-SP4</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="aarch64">
			<FullProductName ProductID="bpftool-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">bpftool-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="bpftool-debuginfo-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">bpftool-debuginfo-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debuginfo-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-debuginfo-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debugsource-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-debugsource-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-devel-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-devel-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-headers-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-headers-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-source-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-source-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-debuginfo-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-devel-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-devel-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="perf-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">perf-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="perf-debuginfo-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">perf-debuginfo-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">python3-perf-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-debuginfo-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">python3-perf-debuginfo-5.10.0-285.0.0.188.oe2203sp4.aarch64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="x86_64">
			<FullProductName ProductID="bpftool-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">bpftool-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="bpftool-debuginfo-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">bpftool-debuginfo-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debuginfo-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-debuginfo-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debugsource-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-debugsource-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-devel-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-devel-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-headers-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-headers-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-source-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-source-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-debuginfo-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-devel-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-devel-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="perf-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">perf-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="perf-debuginfo-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">perf-debuginfo-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">python3-perf-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-debuginfo-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">python3-perf-debuginfo-5.10.0-285.0.0.188.oe2203sp4.x86_64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="src">
			<FullProductName ProductID="kernel-5.10.0-285.0.0.188" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-5.10.0-285.0.0.188.oe2203sp4.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:

NFSD: Protect against send buffer overflow in NFSv2 READ

Since before the git era, NFSD has conserved the number of pages
held by each nfsd thread by combining the RPC receive and send
buffers into a single array of pages. This works because there are
no cases where an operation needs a large RPC Call message and a
large RPC Reply at the same time.

Once an RPC Call has been received, svc_process() updates
svc_rqst::rq_res to describe the part of rq_pages that can be
used for constructing the Reply. This means that the send buffer
(rq_res) shrinks when the received RPC record containing the RPC
Call is large.

A client can force this shrinkage on TCP by sending a correctly-
formed RPC Call header contained in an RPC record that is
excessively large. The full maximum payload size cannot be
constructed in that case.</Note>
		</Notes>
		<ReleaseDate>2025-10-17</ReleaseDate>
		<CVE>CVE-2022-50410</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>High</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>7.1</BaseScore>
				<Vector>AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2025-10-17</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2470</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:

tracing: Limit access to parser-&gt;buffer when trace_get_user failed

When the length of the string written to set_ftrace_filter exceeds
FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:

BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0
Read of size 1 at addr ffff0000d00bd5ba by task ash/165

CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty
Hardware name: linux,dummy-virt (DT)
Call trace:
 show_stack+0x34/0x50 (C)
 dump_stack_lvl+0xa0/0x158
 print_address_description.constprop.0+0x88/0x398
 print_report+0xb0/0x280
 kasan_report+0xa4/0xf0
 __asan_report_load1_noabort+0x20/0x30
 strsep+0x18c/0x1b0
 ftrace_process_regex.isra.0+0x100/0x2d8
 ftrace_regex_release+0x484/0x618
 __fput+0x364/0xa58
 ____fput+0x28/0x40
 task_work_run+0x154/0x278
 do_notify_resume+0x1f0/0x220
 el0_svc+0xec/0xf0
 el0t_64_sync_handler+0xa0/0xe8
 el0t_64_sync+0x1ac/0x1b0

The reason is that trace_get_user will fail when processing a string
longer than FTRACE_BUFF_MAX, but not set the end of parser-&gt;buffer to 0.
Then an OOB access will be triggered in ftrace_regex_release-&gt;
ftrace_process_regex-&gt;strsep-&gt;strpbrk. We can solve this problem by
limiting access to parser-&gt;buffer when trace_get_user failed.</Note>
		</Notes>
		<ReleaseDate>2025-10-17</ReleaseDate>
		<CVE>CVE-2025-39683</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP4</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-17</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2470</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:

vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects

When the &quot;proxy&quot; option is enabled on a VXLAN device, the device will
suppress ARP requests and IPv6 Neighbor Solicitation messages if it is
able to reply on behalf of the remote host. That is, if a matching and
valid neighbor entry is configured on the VXLAN device whose MAC address
is not behind the &quot;any&quot; remote (0.0.0.0 / ::).

The code currently assumes that the FDB entry for the neighbor&apos;s MAC
address points to a valid remote destination, but this is incorrect if
the entry is associated with an FDB nexthop group. This can result in a
NPD [1][3] which can be reproduced using [2][4].

Fix by checking that the remote destination exists before dereferencing
it.

[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
RIP: 0010:vxlan_xmit+0xb58/0x15f0
[...]
Call Trace:
 &lt;TASK&gt;
 dev_hard_start_xmit+0x5d/0x1c0
 __dev_queue_xmit+0x246/0xfd0
 packet_sendmsg+0x113a/0x1850
 __sock_sendmsg+0x38/0x70
 __sys_sendto+0x126/0x180
 __x64_sys_sendto+0x24/0x30
 do_syscall_64+0xa4/0x260
 entry_SYSCALL_64_after_hwframe+0x4b/0x53

[2]
 #!/bin/bash

 ip address add 192.0.2.1/32 dev lo

 ip nexthop add id 1 via 192.0.2.2 fdb
 ip nexthop add id 10 group 1 fdb

 ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy

 ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0

 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10

 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3

[3]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014
RIP: 0010:vxlan_xmit+0x803/0x1600
[...]
Call Trace:
 &lt;TASK&gt;
 dev_hard_start_xmit+0x5d/0x1c0
 __dev_queue_xmit+0x246/0xfd0
 ip6_finish_output2+0x210/0x6c0
 ip6_finish_output+0x1af/0x2b0
 ip6_mr_output+0x92/0x3e0
 ip6_send_skb+0x30/0x90
 rawv6_sendmsg+0xe6e/0x12e0
 __sock_sendmsg+0x38/0x70
 __sys_sendto+0x126/0x180
 __x64_sys_sendto+0x24/0x30
 do_syscall_64+0xa4/0x260
 entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7f383422ec77

[4]
 #!/bin/bash

 ip address add 2001:db8:1::1/128 dev lo

 ip nexthop add id 1 via 2001:db8:1::1 fdb
 ip nexthop add id 10 group 1 fdb

 ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy

 ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0

 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10

 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0</Note>
		</Notes>
		<ReleaseDate>2025-10-17</ReleaseDate>
		<CVE>CVE-2025-39850</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP4</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-17</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2470</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
</cvrfdoc>