OESA-2026-1568

See a problem?
Please try reporting it to the source first.
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-15T05:54:45Z
Modified
2026-03-15T06:19:19.404725Z
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 allocconsistencychecks() 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 checkvalidpointer() 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 macvlancommonnewlink()

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 MACVLANMODESOURCE mode and MACVLANMACADDRADD (or MACVLANMACADDRSET) parameter, lower device already has a macvlan port and registernetdevice() called from macvlancommon_newlink() fails (e.g. because of the invalid link name).

In this case macvlanhashaddsource is called from macvlanchangesources() / macvlancommon_newlink():

This adds a reference to vlan to the port's vlansourcehash using macvlansourceentry.

vlan is a pointer to the priv data of the link that is being created.

When registernetdevice() fails, the error is returned from macvlannewlink() to rtnlnewlinkcreate():

    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 freenetdev() is called, causing a kvfree() on the struct netdevice 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 macvlanforwardsource().

</quote valis>

With all that, my fix is to make sure we call macvlanflushsources() regardless of @create value whenever "goto destroymacvlanport;" 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
0Unknown introduced version / All previous versions are affected
Fixed
4.19.90-2603.2.0.0365.oe2003sp4

Ecosystem specific 

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

Database specific

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