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, &params, 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)
{
"severity": "High"
}{
"aarch64": [
"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"
],
"src": [
"kernel-4.19.90-2603.2.0.0365.oe2003sp4.src.rpm"
],
"x86_64": [
"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"
]
}