An update for kernel is now available for openEuler-20.03-LTS-SP4 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2026-2992 Final 1.0 1.0 2026-07-19 Initial 2026-07-19 2026-07-19 openEuler SA Tool V1.0 2026-07-19 kernel security update An update for kernel is now available for openEuler-20.03-LTS-SP4 The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: ppp: require CAP_NET_ADMIN in target netns for unattached ioctls /dev/ppp open is currently authorized against file->f_cred->user_ns, while unattached administrative ioctls operate on current->nsproxy->net_ns. As a result, a local unprivileged user can create a new user namespace with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace. Require CAP_NET_ADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls. This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case.(CVE-2026-53075) In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().(CVE-2026-53266) An update for kernel is now available for openEuler-20.03-LTS-SP4/openEuler-22.03-LTS-SP3/openEuler-24.03-LTS/openEuler-24.03-LTS-SP2. openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. High kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2992 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-53075 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-53266 https://nvd.nist.gov/vuln/detail/CVE-2026-53075 https://nvd.nist.gov/vuln/detail/CVE-2026-53266 openEuler-20.03-LTS-SP4 bpftool-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm bpftool-debuginfo-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm kernel-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm kernel-debuginfo-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm kernel-debugsource-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm kernel-devel-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm kernel-source-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm kernel-tools-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm kernel-tools-debuginfo-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm kernel-tools-devel-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm perf-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm perf-debuginfo-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm python2-perf-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm python2-perf-debuginfo-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm python3-perf-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm python3-perf-debuginfo-4.19.90-2607.2.0.0380.oe2003sp4.aarch64.rpm bpftool-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm bpftool-debuginfo-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm kernel-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm kernel-debuginfo-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm kernel-debugsource-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm kernel-devel-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm kernel-source-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm kernel-tools-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm kernel-tools-debuginfo-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm kernel-tools-devel-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm perf-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm perf-debuginfo-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm python2-perf-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm python2-perf-debuginfo-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm python3-perf-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm python3-perf-debuginfo-4.19.90-2607.2.0.0380.oe2003sp4.x86_64.rpm kernel-4.19.90-2607.2.0.0380.oe2003sp4.src.rpm In the Linux kernel, the following vulnerability has been resolved: ppp: require CAP_NET_ADMIN in target netns for unattached ioctls /dev/ppp open is currently authorized against file->f_cred->user_ns, while unattached administrative ioctls operate on current->nsproxy->net_ns. As a result, a local unprivileged user can create a new user namespace with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace. Require CAP_NET_ADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls. This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case. 2026-07-19 CVE-2026-53075 openEuler-20.03-LTS-SP4 High 8.8 AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H kernel security update 2026-07-19 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2992 In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits(). 2026-07-19 CVE-2026-53266 openEuler-20.03-LTS-SP4 High 8.8 AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H kernel security update 2026-07-19 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2992