{"schema_version":"1.7.2","id":"OESA-2026-1568","modified":"2026-03-15T05:54:45Z","published":"2026-03-15T05:54:45Z","upstream":["CVE-2025-39902","CVE-2026-23209"],"summary":"kernel security update","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<quote valis>\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'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->newlink)\n                err = ops->newlink(dev, &params, extack);\n        else\n                err = register_netdevice(dev);\n        if (err < 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'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</quote valis>\n\nWith all that, my fix is to make sure we call macvlan_flush_sources()\nregardless of @create value whenever "goto destroy_macvlan_port;"\npath is taken.\n\nMany thanks to valis for following up on this issue.(CVE-2026-23209)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"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"]}}],"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"}],"database_specific":{"severity":"High"}}