OESA-2026-2310 (CVE-2026-31504)

Vulnerability from osv_openeuler – Published: 2026-05-15 11:11 – Updated: 2026-08-06 11:11 – 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:

net: fix fanout UAF in packet_release() via NETDEV_UP race

packet_release() has a race window where NETDEV_UP can re-register a socket into a fanout group's arr[] array. The re-registration is not cleaned up by fanout_release(), leaving a dangling pointer in the fanout array. packet_release() does NOT zero po->num in its bind_lock section. After releasing bind_lock, po->num is still non-zero and po->ifindex still matches the bound device. A concurrent packet_notifier(NETDEV_UP) that already found the socket in sklist can re-register the hook. For fanout sockets, this re-registration calls __fanout_link(sk, po) which adds the socket back into f->arr[] and increments f->num_members, but does NOT increment f->sk_ref.

The fix sets po->num to zero in packet_release while bind_lock is held to prevent NETDEV_UP from linking, preventing the race window.

This bug was found following an additional audit with Claude Code based on CVE-2025-38617.(CVE-2026-31504)

In the Linux kernel, the following vulnerability has been resolved:

af_key: validate families in pfkey_send_migrate()

syzbot was able to trigger a crash in skb_put() [1]

Issue is that pfkey_send_migrate() does not check old/new families, and that set_ipsecrequest() @family argument was truncated, thus possibly overfilling the skb.

Validate families early, do not wait set_ipsecrequest().

[1]

skbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev:<NULL> kernel BUG at net/core/skbuff.c:214 ! Call Trace: <TASK> skb_over_panic net/core/skbuff.c:219 [inline] skb_put+0x159/0x210 net/core/skbuff.c:2655 skb_put_zero include/linux/skbuff.h:2788 [inline] set_ipsecrequest net/key/af_key.c:3532 [inline] pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636 km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848 xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705 xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150(CVE-2026-31515)

In the Linux kernel, the following vulnerability has been resolved:

rxrpc: proc: size address buffers for %pISpc output

The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with "%pISpc".

That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap().

As a result, a case such as

is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c.

Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf().

Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example(CVE-2026-31630)

In the Linux kernel, the following vulnerability has been resolved:

af_unix: read UNIX_DIAG_VFS data under unix_state_lock

Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unix_release_sock() clears u->path under unix_state_lock() and drops the path reference after unlocking.

Read the inode and device numbers for UNIX_DIAG_VFS while holding unix_state_lock(), then emit the netlink attribute after dropping the lock.

This keeps the VFS data stable while the reply is being built.(CVE-2026-31673)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check()

Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS.

rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[]. Validate addrnr during rule installation so malformed rules are rejected before the match logic can use an out-of-range value.(CVE-2026-31674)

In the Linux kernel, the following vulnerability has been resolved:

bridge: br_nd_send: linearize skb before parsing ND options

br_nd_send() parses neighbour discovery options from ns->opt[] and assumes that these options are in the linear part of request.

Its callers only guarantee that the ICMPv6 header and target address are available, so the option area can still be non-linear. Parsing ns->opt[] in that case can access data past the linear buffer.

Linearize request before option parsing and derive ns from the linear network header.(CVE-2026-31682)

In 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)

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

{
  "affected": [
    {
      "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"
        ]
      },
      "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-2605.3.0.0372.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "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\u0026apos;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-\u0026gt;num` in its `bind_lock` section.\nAfter releasing `bind_lock`, `po-\u0026gt;num` is still non-zero and `po-\u0026gt;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-\u0026gt;arr[]` and increments `f-\u0026gt;num_members`,\nbut does NOT increment `f-\u0026gt;sk_ref`.\n\nThe fix sets `po-\u0026gt;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:\u0026lt;NULL\u0026gt;\n kernel BUG at net/core/skbuff.c:214 !\nCall Trace:\n \u0026lt;TASK\u0026gt;\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 \u0026quot;%pISpc\u0026quot;.\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\u0026apos;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-\u0026gt;path. Meanwhile, unix_release_sock() clears u-\u0026gt;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-\u0026gt;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-\u0026gt;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-\u0026gt;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)",
  "id": "OESA-2026-2310",
  "modified": "2026-08-06T11:11:16Z",
  "published": "2026-05-15T11:11:16Z",
  "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"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2026-31504",
    "CVE-2026-31515",
    "CVE-2026-31630",
    "CVE-2026-31673",
    "CVE-2026-31674",
    "CVE-2026-31682",
    "CVE-2026-43284"
  ]
}



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.