OESA-2026-1568

Source
https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2026-1568
Import Source
https://repo.openeuler.org/security/data/osv/OESA-2026-1568.json
JSON Data
https://api.osv.dev/v1/vulns/OESA-2026-1568
Upstream
Published
2026-03-15T11:10:34Z
Modified
2026-08-18T01:19:36Z
Severity
  • 7.0 (High) CVSS_V3 - CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H CVSS Calculator
Summary
kernel security update
Details

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-&gt;newlink)
            err = ops-&gt;newlink(dev, &amp;params, extack);
    else
            err = register_netdevice(dev);
    if (err &lt; 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)

Database specific
{
    "severity": "High"
}
References

Affected packages

openEuler:20.03-LTS-SP4 / kernel

Package

Name
kernel
Purl
pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0 Unknown introduced version / All previous versions are affected
Fixed
4.19.90-2603.2.0.0365.oe2003sp4

Ecosystem specific

{
    "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"
    ]
}

Database specific

source
"https://repo.openeuler.org/security/data/osv/OESA-2026-1568.json"