An update for kernel is now available for openEuler-20.03-LTS-SP4
Security Advisory
openeuler-security@openeuler.org
openEuler security committee
openEuler-SA-2026-1568
Final
1.0
1.0
2026-03-15
Initial
2026-03-15
2026-03-15
openEuler SA Tool V1.0
2026-03-15
kernel security update
An update for kernel is now available for openEuler-20.03-LTS-SP4
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
mm/slub: avoid accessing metadata when pointer is invalid in object_err()
object_err() reports details of an object for further debugging, such as
the freelist pointer, redzone, etc. However, if the pointer is invalid,
attempting to access object metadata can lead to a crash since it does
not point to a valid object.
One known path to the crash is when alloc_consistency_checks()
determines the pointer to the allocated object is invalid because of a
freelist corruption, and calls object_err() to report it. The debug code
should report and handle the corruption gracefully and not crash in the
process.
In case the pointer is NULL or check_valid_pointer() returns false for
the pointer, only print the pointer value and skip accessing metadata.(CVE-2025-39902)
In the Linux kernel, the following vulnerability has been resolved:
macvlan: fix error recovery in macvlan_common_newlink()
valis provided a nice repro to crash the kernel:
ip link add p1 type veth peer p2
ip link set address 00:00:00:00:00:20 dev p1
ip link set up dev p1
ip link set up dev p2
ip link add mv0 link p2 type macvlan mode source
ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20
ping -c1 -I p1 1.2.3.4
He also gave a very detailed analysis:
<quote valis>
The issue is triggered when a new macvlan link is created with
MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or
MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan
port and register_netdevice() called from macvlan_common_newlink()
fails (e.g. because of the invalid link name).
In this case macvlan_hash_add_source is called from
macvlan_change_sources() / macvlan_common_newlink():
This adds a reference to vlan to the port's vlan_source_hash using
macvlan_source_entry.
vlan is a pointer to the priv data of the link that is being created.
When register_netdevice() fails, the error is returned from
macvlan_newlink() to rtnl_newlink_create():
if (ops->newlink)
err = ops->newlink(dev, ¶ms, extack);
else
err = register_netdevice(dev);
if (err < 0) {
free_netdev(dev);
goto out;
}
and free_netdev() is called, causing a kvfree() on the struct
net_device that is still referenced in the source entry attached to
the lower device's macvlan port.
Now all packets sent on the macvlan port with a matching source mac
address will trigger a use-after-free in macvlan_forward_source().
</quote valis>
With all that, my fix is to make sure we call macvlan_flush_sources()
regardless of @create value whenever "goto destroy_macvlan_port;"
path is taken.
Many thanks to valis for following up on this issue.(CVE-2026-23209)
An update for kernel is now available for openEuler-20.03-LTS-SP4.
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.
High
kernel
https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1568
https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39902
https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23209
https://nvd.nist.gov/vuln/detail/CVE-2025-39902
https://nvd.nist.gov/vuln/detail/CVE-2026-23209
openEuler-20.03-LTS-SP4
bpftool-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
bpftool-debuginfo-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
kernel-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
kernel-debuginfo-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
kernel-debugsource-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
kernel-devel-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
kernel-source-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
kernel-tools-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
kernel-tools-debuginfo-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
kernel-tools-devel-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
perf-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
perf-debuginfo-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
python2-perf-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
python2-perf-debuginfo-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
python3-perf-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
python3-perf-debuginfo-4.19.90-2603.2.0.0365.oe2003sp4.x86_64.rpm
kernel-4.19.90-2603.2.0.0365.oe2003sp4.src.rpm
bpftool-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
bpftool-debuginfo-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
kernel-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
kernel-debuginfo-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
kernel-debugsource-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
kernel-devel-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
kernel-source-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
kernel-tools-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
kernel-tools-debuginfo-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
kernel-tools-devel-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
perf-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
perf-debuginfo-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
python2-perf-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
python2-perf-debuginfo-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
python3-perf-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
python3-perf-debuginfo-4.19.90-2603.2.0.0365.oe2003sp4.aarch64.rpm
In the Linux kernel, the following vulnerability has been resolved:
mm/slub: avoid accessing metadata when pointer is invalid in object_err()
object_err() reports details of an object for further debugging, such as
the freelist pointer, redzone, etc. However, if the pointer is invalid,
attempting to access object metadata can lead to a crash since it does
not point to a valid object.
One known path to the crash is when alloc_consistency_checks()
determines the pointer to the allocated object is invalid because of a
freelist corruption, and calls object_err() to report it. The debug code
should report and handle the corruption gracefully and not crash in the
process.
In case the pointer is NULL or check_valid_pointer() returns false for
the pointer, only print the pointer value and skip accessing metadata.
2026-03-15
CVE-2025-39902
openEuler-20.03-LTS-SP4
Medium
5.5
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
kernel security update
2026-03-15
https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1568
In the Linux kernel, the following vulnerability has been resolved:
macvlan: fix error recovery in macvlan_common_newlink()
valis provided a nice repro to crash the kernel:
ip link add p1 type veth peer p2
ip link set address 00:00:00:00:00:20 dev p1
ip link set up dev p1
ip link set up dev p2
ip link add mv0 link p2 type macvlan mode source
ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20
ping -c1 -I p1 1.2.3.4
He also gave a very detailed analysis:
<quote valis>
The issue is triggered when a new macvlan link is created with
MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or
MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan
port and register_netdevice() called from macvlan_common_newlink()
fails (e.g. because of the invalid link name).
In this case macvlan_hash_add_source is called from
macvlan_change_sources() / macvlan_common_newlink():
This adds a reference to vlan to the port's vlan_source_hash using
macvlan_source_entry.
vlan is a pointer to the priv data of the link that is being created.
When register_netdevice() fails, the error is returned from
macvlan_newlink() to rtnl_newlink_create():
if (ops->newlink)
err = ops->newlink(dev, ¶ms, extack);
else
err = register_netdevice(dev);
if (err < 0) {
free_netdev(dev);
goto out;
}
and free_netdev() is called, causing a kvfree() on the struct
net_device that is still referenced in the source entry attached to
the lower device's macvlan port.
Now all packets sent on the macvlan port with a matching source mac
address will trigger a use-after-free in macvlan_forward_source().
</quote valis>
With all that, my fix is to make sure we call macvlan_flush_sources()
regardless of @create value whenever "goto destroy_macvlan_port;"
path is taken.
Many thanks to valis for following up on this issue.
2026-03-15
CVE-2026-23209
openEuler-20.03-LTS-SP4
High
7.0
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
kernel security update
2026-03-15
https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1568