OESA-2026-1568 (CVE-2025-39902)

Vulnerability from osv_openeuler – Published: 2026-03-15 11:10 – Updated: 2026-08-06 11:10 – Source website
VLAI
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)

Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "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"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2603.2.0.0365.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: avoid accessing metadata when pointer is invalid in object_err()\n\nobject_err() reports details of an object for further debugging, such as\nthe freelist pointer, redzone, etc. However, if the pointer is invalid,\nattempting to access object metadata can lead to a crash since it does\nnot point to a valid object.\n\nOne known path to the crash is when alloc_consistency_checks()\ndetermines the pointer to the allocated object is invalid because of a\nfreelist corruption, and calls object_err() to report it. The debug code\nshould report and handle the corruption gracefully and not crash in the\nprocess.\n\nIn case the pointer is NULL or check_valid_pointer() returns false for\nthe pointer, only print the pointer value and skip accessing metadata.(CVE-2025-39902)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: fix error recovery in macvlan_common_newlink()\n\nvalis provided a nice repro to crash the kernel:\n\nip link add p1 type veth peer p2\nip link set address 00:00:00:00:00:20 dev p1\nip link set up dev p1\nip link set up dev p2\n\nip link add mv0 link p2 type macvlan mode source\nip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20\n\nping -c1 -I p1 1.2.3.4\n\nHe also gave a very detailed analysis:\n\n\u0026lt;quote valis\u0026gt;\n\nThe issue is triggered when a new macvlan link is created  with\nMACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or\nMACVLAN_MACADDR_SET) parameter, lower device already has a macvlan\nport and register_netdevice() called from macvlan_common_newlink()\nfails (e.g. because of the invalid link name).\n\nIn this case macvlan_hash_add_source is called from\nmacvlan_change_sources() / macvlan_common_newlink():\n\nThis adds a reference to vlan to the port\u0026apos;s vlan_source_hash using\nmacvlan_source_entry.\n\nvlan is a pointer to the priv data of the link that is being created.\n\nWhen register_netdevice() fails, the error is returned from\nmacvlan_newlink() to rtnl_newlink_create():\n\n        if (ops-\u0026gt;newlink)\n                err = ops-\u0026gt;newlink(dev, \u0026amp;params, extack);\n        else\n                err = register_netdevice(dev);\n        if (err \u0026lt; 0) {\n                free_netdev(dev);\n                goto out;\n        }\n\nand free_netdev() is called, causing a kvfree() on the struct\nnet_device that is still referenced in the source entry attached to\nthe lower device\u0026apos;s macvlan port.\n\nNow all packets sent on the macvlan port with a matching source mac\naddress will trigger a use-after-free in macvlan_forward_source().\n\n\u0026lt;/quote valis\u0026gt;\n\nWith all that, my fix is to make sure we call macvlan_flush_sources()\nregardless of @create value whenever \u0026quot;goto destroy_macvlan_port;\u0026quot;\npath is taken.\n\nMany thanks to valis for following up on this issue.(CVE-2026-23209)",
  "id": "OESA-2026-1568",
  "modified": "2026-08-06T11:10:34Z",
  "published": "2026-03-15T11:10:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1568"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39902"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23209"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2025-39902",
    "CVE-2026-23209"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.