{"schema_version":"1.7.2","id":"OESA-2026-2310","modified":"2026-05-15T14:00:32Z","published":"2026-05-15T14:00:32Z","upstream":["CVE-2026-31504","CVE-2026-31515","CVE-2026-31630","CVE-2026-31673","CVE-2026-31674","CVE-2026-31682","CVE-2026-43284"],"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\nnet: fix fanout UAF in packet_release() via NETDEV_UP race\n\n`packet_release()` has a race window where `NETDEV_UP` can re-register a\nsocket into a fanout group's `arr[]` array. The re-registration is not\ncleaned up by `fanout_release()`, leaving a dangling pointer in the fanout\narray.\n`packet_release()` does NOT zero `po->num` in its `bind_lock` section.\nAfter releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex`\nstill matches the bound device. A concurrent `packet_notifier(NETDEV_UP)`\nthat already found the socket in `sklist` can re-register the hook.\nFor fanout sockets, this re-registration calls `__fanout_link(sk, po)`\nwhich adds the socket back into `f->arr[]` and increments `f->num_members`,\nbut does NOT increment `f->sk_ref`.\n\nThe fix sets `po->num` to zero in `packet_release` while `bind_lock` is\nheld to prevent NETDEV_UP from linking, preventing the race window.\n\nThis bug was found following an additional audit with Claude Code based\non CVE-2025-38617.(CVE-2026-31504)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_key: validate families in pfkey_send_migrate()\n\nsyzbot was able to trigger a crash in skb_put() [1]\n\nIssue is that pfkey_send_migrate() does not check old/new families,\nand that set_ipsecrequest() @family argument was truncated,\nthus possibly overfilling the skb.\n\nValidate families early, do not wait set_ipsecrequest().\n\n[1]\n\nskbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev:<NULL>\n kernel BUG at net/core/skbuff.c:214 !\nCall Trace:\n <TASK>\n  skb_over_panic net/core/skbuff.c:219 [inline]\n  skb_put+0x159/0x210 net/core/skbuff.c:2655\n  skb_put_zero include/linux/skbuff.h:2788 [inline]\n  set_ipsecrequest net/key/af_key.c:3532 [inline]\n  pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636\n  km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848\n  xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705\n  xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150(CVE-2026-31515)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: proc: size address buffers for %pISpc output\n\nThe AF_RXRPC procfs helpers format local and remote socket addresses into\nfixed 50-byte stack buffers with "%pISpc".\n\nThat is too small for the longest current-tree IPv6-with-port form the\nformatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a\ndotted-quad tail not only for v4mapped addresses, but also for ISATAP\naddresses via ipv6_addr_is_isatap().\n\nAs a result, a case such as\n\n  [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535\n\nis possible with the current formatter. That is 50 visible characters, so\n51 bytes including the trailing NUL, which does not fit in the existing\nchar[50] buffers used by net/rxrpc/proc.c.\n\nSize the buffers from the formatter's maximum textual form and switch the\ncall sites to scnprintf().\n\nChanges since v1:\n- correct the changelog to cite the actual maximum current-tree case\n  explicitly\n- frame the proof around the ISATAP formatting path instead of the earlier\n  mapped-v4 example(CVE-2026-31630)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: read UNIX_DIAG_VFS data under unix_state_lock\n\nExact UNIX diag lookups hold a reference to the socket, but not to\nu->path. Meanwhile, unix_release_sock() clears u->path under\nunix_state_lock() and drops the path reference after unlocking.\n\nRead the inode and device numbers for UNIX_DIAG_VFS while holding\nunix_state_lock(), then emit the netlink attribute after dropping the\nlock.\n\nThis keeps the VFS data stable while the reply is being built.(CVE-2026-31673)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check()\n\nReject rt match rules whose addrnr exceeds IP6T_RT_HOPS.\n\nrt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[].\nValidate addrnr during rule installation so malformed rules are rejected\nbefore the match logic can use an out-of-range value.(CVE-2026-31674)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbridge: br_nd_send: linearize skb before parsing ND options\n\nbr_nd_send() parses neighbour discovery options from ns->opt[] and\nassumes that these options are in the linear part of request.\n\nIts callers only guarantee that the ICMPv6 header and target address\nare available, so the option area can still be non-linear. Parsing\nns->opt[] in that case can access data past the linear buffer.\n\nLinearize request before option parsing and derive ns from the linear\nnetwork header.(CVE-2026-31682)\n\nIn the Linux kernel xfrm/ESP (IPsec) subsystem, when appending pipe pages to network packets (skb) via zero-copy mechanisms such as splice() / MSG_SPLICE_PAGES, IPv4/IPv6 datagram paths are not correctly marked with the SKBFL_SHARED_FRAG flag. The ESP receive path incorrectly treats these externally owned shared pages as private data, skipping the COW (copy-on-write) step and performing in-place decryption directly, allowing an attacker to pollute otherwise read-only pages in the page cache. Combined with CVE-2026-43500, a complete exploit chain can be formed, allowing local unprivileged users to obtain root privileges. This vulnerability affects almost all Linux distributions since 2017 (kernel ~ 4.10), including Ubuntu, RHEL, AlmaLinux, Debian, Fedora, etc. A public PoC has been released and signs of active exploitation have been observed.(CVE-2026-43284)","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-2605.3.0.0372.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","kernel-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","perf-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2605.3.0.0372.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2605.3.0.0372.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","kernel-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","perf-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2605.3.0.0372.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2310"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31504"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31515"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31630"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31673"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31674"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31682"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43284"}],"database_specific":{"severity":"Critical"}}