GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2026-3701 (CVE-2021-47358)

Vulnerability from osv_openeuler – Published: 2026-09-05 15:04 – Updated: 2026-09-05 15:04 – 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:

staging: greybus: uart: fix tty use after free

User space can hold a tty open indefinitely and tty drivers must not release the underlying structures until the last user is gone.

Switch to using the tty-port reference counter to manage the life time of the greybus tty state to avoid use after free after a disconnect.(CVE-2021-47358)

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

net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs

When shrinking the number of real tx queues, netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush qdiscs for queues which will no longer be used.

qdisc_reset_all_tx_gt() currently serializes qdisc_reset() with qdisc_lock(). However, for lockless qdiscs, the dequeue path is serialized by qdisc_run_begin/end() using qdisc->seqlock instead, so qdisc_reset() can run concurrently with __qdisc_run() and free skbs while they are still being dequeued, leading to UAF.

This can easily be reproduced on e.g. virtio-net by imposing heavy traffic while frequently changing the number of queue pairs:

iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 done

With KASAN enabled, this leads to reports like:

BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: <TASK> ... __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 udp_sendmsg+0x13c9/0x1fc0 ... </TASK>

Allocated by task 1270 on cpu 5 at 44.558414s: ... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg+0x13a6/0x1fc0 ...

Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a/0x890 ...

Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path by taking qdisc->seqlock for TCQ_F_NOLOCK qdiscs, matching the serialization model already used by dev_reset_queue().

Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state reflects an empty queue, avoiding needless re-scheduling.(CVE-2026-23340)

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

seg6: separate dst_cache for input and output paths in seg6 lwtunnel

The seg6 lwtunnel uses a single dst_cache per encap route, shared between seg6_input_core() and seg6_output_core(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup.

Fix this by splitting the cache into cache_input and cache_output, so each path maintains its own cached dst independently.(CVE-2026-31668)

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

libceph: Fix potential out-of-bounds access in crush_decode()

A message of type CEPH_MSG_OSD_MAP containing a crush map with at least one bucket has two fields holding the bucket algorithm. If the values in these two fields differ, an out-of-bounds access can occur. This is the case because the first algorithm field (alg) is used to allocate the correct amount of memory for a bucket of this type, while the second algorithm field inside the bucket (b->alg) is used in the subsequent processing.

This patch fixes the issue by adding a check that compares alg and b->alg and aborts the processing in case they differ. Furthermore, b->alg is set to 0 in this case, because the destruction of the crush map also uses this field to determine the bucket type, which can again result in an out-of-bounds access when trying to free the memory pointed to by the fields of the bucket. To correctly free the memory allocated for the bucket in such a case, the corresponding call to kfree is moved from the algorithm-specific crush_destroy_bucket functions to the generic crush_destroy_bucket().(CVE-2026-52955)

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

netfilter: nfnetlink_osf: fix out-of-bounds read on option matching

In nf_osf_match(), the nf_osf_hdr_ctx structure is initialized once and passed by reference to nf_osf_match_one() for each fingerprint checked. During TCP option parsing, nf_osf_match_one() advances the shared ctx->optp pointer.

If a fingerprint perfectly matches, the function returns early without restoring ctx->optp to its initial state. If the user has configured NF_OSF_LOGLEVEL_ALL, the loop continues to the next fingerprint. However, because ctx->optp was not restored, the next call to nf_osf_match_one() starts parsing from the end of the options buffer. This causes subsequent matches to read garbage data and fail immediately, making it impossible to log more than one match or logging incorrect matches.

Instead of using a shared ctx->optp pointer, pass the context as a constant pointer and use a local pointer (optp) for TCP option traversal. This makes nf_osf_match_one() strictly stateless from the caller's perspective, ensuring every fingerprint check starts at the correct option offset.(CVE-2026-52999)

In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr(). ip6t_eui64, xt_mac, the bitmap:ip,mac, hash:ip,mac, and hash:mac ipset types, and nf_log_syslog access eth_hdr(skb) after either assuming that the skb is associated with an Ethernet device or checking only that the ETH_HLEN bytes at skb_mac_header(skb) lie between skb-&gt;head and skb-&gt;data. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing eth_hdr(skb).(CVE-2026-53131)

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

ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()

In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels:

  • Tunnels matching the packet's local address, with any remote address wildcard remote).

  • Tunnels matching the packet's remote address, with any local address (wildcard local).

However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions.

The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.(CVE-2026-53221)

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

sctp: fix uninit-value in __sctp_rcv_asconf_lookup()

__sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->from_addr_param(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length.

An unauthenticated peer can send a truncated trailing ASCONF chunk that declares an IPv6 address parameter but stops after the 4-byte parameter header; reached from the no-association lookup path, from_addr_param() then reads uninitialized bytes past the parameter.

Impact: an unauthenticated SCTP peer makes the receive path read up to 16 bytes of uninitialized memory past a truncated ASCONF address parameter.

The sibling __sctp_rcv_init_lookup() bounds parameters with sctp_walk_params(); this path open-codes the fetch and omits the bound. Verify the whole address parameter lies within the chunk before from_addr_param() reads it, the same class of fix as commit 51e5ad549c43 ("net: sctp: fix KMSAN uninit-value in sctp_inq_pop").(CVE-2026-53225)

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

ipv6: sit: reload inner IPv6 header after GSO offloads

ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads().

For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call.

If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released.

Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb.(CVE-2026-53228)

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

sctp: don't free the ASCONF's own transport in DEL-IP processing

sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address.

sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order:

[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]

where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory.

Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.(CVE-2026-64564)

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

libceph: refresh auth->authorizer_buf{,_len} after authorizer update

ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer.

ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory.

A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer.

Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.(CVE-2026-68156)

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

IB/mad: Drop unmatched RMPP responses before reassembly

Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment.

That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send.

For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state.

This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.(CVE-2026-68425)

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

RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path

For non-SRQ QPs, the responder reads WQE fields directly from the shared queue buffer mapped into userspace. This allows a malicious user to modify fields like num_sge or sge entries while the kernel is processing the WQE, leading to out-of-bounds reads in rxe_resp_check_length() and copy_data().

Introduce get_recv_wqe() that validates num_sge and copies the WQE to a kernel-local buffer before processing, matching the approach already used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is reused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)

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

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2608.6.0.0388.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2608.6.0.0388.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2608.6.0.0388.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2608.6.0.0388.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-2608.6.0.0388.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\nstaging: greybus: uart: fix tty use after free\n\nUser space can hold a tty open indefinitely and tty drivers must not\nrelease the underlying structures until the last user is gone.\n\nSwitch to using the tty-port reference counter to manage the life time\nof the greybus tty state to avoid use after free after a disconnect.(CVE-2021-47358)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs\n\nWhen shrinking the number of real tx queues,\nnetif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush\nqdiscs for queues which will no longer be used.\n\nqdisc_reset_all_tx_gt() currently serializes qdisc_reset() with\nqdisc_lock(). However, for lockless qdiscs, the dequeue path is\nserialized by qdisc_run_begin/end() using qdisc-\u0026gt;seqlock instead, so\nqdisc_reset() can run concurrently with __qdisc_run() and free skbs\nwhile they are still being dequeued, leading to UAF.\n\nThis can easily be reproduced on e.g. virtio-net by imposing heavy\ntraffic while frequently changing the number of queue pairs:\n\n  iperf3 -ub0 -c $peer -t 0 \u0026amp;\n  while :; do\n    ethtool -L eth0 combined 1\n    ethtool -L eth0 combined 2\n  done\n\nWith KASAN enabled, this leads to reports like:\n\n  BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760\n  ...\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ...\n   __qdisc_run+0x133f/0x1760\n   __dev_queue_xmit+0x248f/0x3550\n   ip_finish_output2+0xa42/0x2110\n   ip_output+0x1a7/0x410\n   ip_send_skb+0x2e6/0x480\n   udp_send_skb+0xb0a/0x1590\n   udp_sendmsg+0x13c9/0x1fc0\n   ...\n   \u0026lt;/TASK\u0026gt;\n\n  Allocated by task 1270 on cpu 5 at 44.558414s:\n   ...\n   alloc_skb_with_frags+0x84/0x7c0\n   sock_alloc_send_pskb+0x69a/0x830\n   __ip_append_data+0x1b86/0x48c0\n   ip_make_skb+0x1e8/0x2b0\n   udp_sendmsg+0x13a6/0x1fc0\n   ...\n\n  Freed by task 1306 on cpu 3 at 44.558445s:\n   ...\n   kmem_cache_free+0x117/0x5e0\n   pfifo_fast_reset+0x14d/0x580\n   qdisc_reset+0x9e/0x5f0\n   netif_set_real_num_tx_queues+0x303/0x840\n   virtnet_set_channels+0x1bf/0x260 [virtio_net]\n   ethnl_set_channels+0x684/0xae0\n   ethnl_default_set_doit+0x31a/0x890\n   ...\n\nSerialize qdisc_reset_all_tx_gt() against the lockless dequeue path by\ntaking qdisc-\u0026gt;seqlock for TCQ_F_NOLOCK qdiscs, matching the\nserialization model already used by dev_reset_queue().\n\nAdditionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state\nreflects an empty queue, avoiding needless re-scheduling.(CVE-2026-23340)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nseg6: separate dst_cache for input and output paths in seg6 lwtunnel\n\nThe seg6 lwtunnel uses a single dst_cache per encap route, shared\nbetween seg6_input_core() and seg6_output_core(). These two paths\ncan perform the post-encap SID lookup in different routing contexts\n(e.g., ip rules matching on the ingress interface, or VRF table\nseparation). Whichever path runs first populates the cache, and the\nother reuses it blindly, bypassing its own lookup.\n\nFix this by splitting the cache into cache_input and cache_output,\nso each path maintains its own cached dst independently.(CVE-2026-31668)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: Fix potential out-of-bounds access in crush_decode()\n\nA message of type CEPH_MSG_OSD_MAP containing a crush map with at least\none bucket has two fields holding the bucket algorithm. If the values\nin these two fields differ, an out-of-bounds access can occur. This is\nthe case because the first algorithm field (alg) is used to allocate\nthe correct amount of memory for a bucket of this type, while the second\nalgorithm field inside the bucket (b-\u0026gt;alg) is used in the subsequent\nprocessing.\n\nThis patch fixes the issue by adding a check that compares alg and\nb-\u0026gt;alg and aborts the processing in case they differ. Furthermore,\nb-\u0026gt;alg is set to 0 in this case, because the destruction of the crush\nmap also uses this field to determine the bucket type, which can again\nresult in an out-of-bounds access when trying to free the memory pointed\nto by the fields of the bucket. To correctly free the memory allocated\nfor the bucket in such a case, the corresponding call to kfree is moved\nfrom the algorithm-specific crush_destroy_bucket functions to the\ngeneric crush_destroy_bucket().(CVE-2026-52955)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_osf: fix out-of-bounds read on option matching\n\nIn nf_osf_match(), the nf_osf_hdr_ctx structure is initialized once\nand passed by reference to nf_osf_match_one() for each fingerprint\nchecked. During TCP option parsing, nf_osf_match_one() advances the\nshared ctx-\u0026gt;optp pointer.\n\nIf a fingerprint perfectly matches, the function returns early without\nrestoring ctx-\u0026gt;optp to its initial state. If the user has configured\nNF_OSF_LOGLEVEL_ALL, the loop continues to the next fingerprint.\nHowever, because ctx-\u0026gt;optp was not restored, the next call to\nnf_osf_match_one() starts parsing from the end of the options buffer.\nThis causes subsequent matches to read garbage data and fail\nimmediately, making it impossible to log more than one match or logging\nincorrect matches.\n\nInstead of using a shared ctx-\u0026gt;optp pointer, pass the context as a\nconstant pointer and use a local pointer (optp) for TCP option\ntraversal. This makes nf_osf_match_one() strictly stateless from the\ncaller\u0026apos;s perspective, ensuring every fingerprint check starts at the\ncorrect option offset.(CVE-2026-52999)\n\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr(). `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb-\u0026gt;head` and `skb-\u0026gt;data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.(CVE-2026-53131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()\n\nIn vti6_tnl_lookup(), when an exact match for a tunnel fails,\nthe code falls back to searching for wildcard tunnels:\n\n- Tunnels matching the packet\u0026apos;s local address, with any remote address\n  wildcard remote).\n\n- Tunnels matching the packet\u0026apos;s remote address, with any local address\n  (wildcard local).\n\nHowever, vti6 stores all these different types of tunnels in the same\nhash table (ip6n-\u0026gt;tnls_r_l) prone to hash collisions.\n\nThe bug is that the fallback search loops in vti6_tnl_lookup() were\nmissing checks to ensure that the candidate tunnel actually has\na wildcard address.(CVE-2026-53221)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix uninit-value in __sctp_rcv_asconf_lookup()\n\n__sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF\nchunk can hold the ADDIP header and a parameter header, then calls\naf-\u0026gt;from_addr_param(), which reads the full address (16 bytes for IPv6)\ntrusting the parameter\u0026apos;s declared length.\n\nAn unauthenticated peer can send a truncated trailing ASCONF chunk that\ndeclares an IPv6 address parameter but stops after the 4-byte parameter\nheader; reached from the no-association lookup path, from_addr_param() then\nreads uninitialized bytes past the parameter.\n\nImpact: an unauthenticated SCTP peer makes the receive path read up to 16\nbytes of uninitialized memory past a truncated ASCONF address parameter.\n\nThe sibling __sctp_rcv_init_lookup() bounds parameters with\nsctp_walk_params(); this path open-codes the fetch and omits the bound.\nVerify the whole address parameter lies within the chunk before\nfrom_addr_param() reads it, the same class of fix as commit 51e5ad549c43\n(\u0026quot;net: sctp: fix KMSAN uninit-value in sctp_inq_pop\u0026quot;).(CVE-2026-53225)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: sit: reload inner IPv6 header after GSO offloads\n\nipip6_tunnel_xmit() caches the inner IPv6 header pointer at function\nentry and continues using it after iptunnel_handle_offloads().\n\nFor GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone().\nWhen the skb header is cloned, skb_header_unclone() can call\npskb_expand_head(), which may move the skb head. The pskb_expand_head()\ncontract requires pointers into the skb header to be reloaded after the\ncall.\n\nIf the later skb_realloc_headroom() branch is not taken, SIT uses the\nstale iph6 pointer to read the inner hop limit and DS field. That can\nread from a freed skb head after the old head\u0026apos;s remaining clone is\nreleased.\n\nReload iph6 after the offload helper succeeds and before subsequent\nreads from the inner IPv6 header. Keep the existing reload after\nskb_realloc_headroom(), since that branch can also replace the skb.(CVE-2026-53228)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: don\u0026apos;t free the ASCONF\u0026apos;s own transport in DEL-IP processing\n\nsctp_process_asconf() caches the transport the ASCONF chunk is processed\nagainst in asconf-\u0026gt;transport (== chunk-\u0026gt;transport, set once in sctp_rcv()).\nFor an ASCONF located through its Address Parameter by\n__sctp_rcv_asconf_lookup(), that cached transport corresponds to the\nAddress Parameter, which need not be the packet\u0026apos;s source address.\n\nsctp_process_asconf_param() rejects a DEL-IP for the packet source address\n(ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf-\u0026gt;transport.\nA single ASCONF can therefore carry, in order:\n\n    [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]\n\nwhere L differs from the source. The DEL-IP for L passes the D8 check and\ncalls sctp_assoc_rm_peer() on the transport that asconf-\u0026gt;transport still\npoints at, freeing it (RCU-deferred). The following wildcard DEL-IP then\nreuses the now-dangling asconf-\u0026gt;transport in sctp_assoc_set_primary() and\nsctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed\ntransport (-\u0026gt;ipaddr, -\u0026gt;state) and plants the dangling pointer into\nasoc-\u0026gt;peer.primary_path / active_path, and del_nonprimary_peers(), keeping\nonly the pointer that is no longer on the list, removes every real\ntransport, leaving the association with a transport_count of 0 and\nprimary_path/active_path pointing at freed memory.\n\nReject a DEL-IP that targets the transport the ASCONF is being processed\nagainst, mirroring the existing source-address guard, so the wildcard\nbranch can never reuse a freed transport.(CVE-2026-64564)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: refresh auth-\u0026gt;authorizer_buf{,_len} after authorizer update\n\nceph_x_create_authorizer() caches au-\u0026gt;buf-\u0026gt;vec.iov_base and\nau-\u0026gt;buf-\u0026gt;vec.iov_len in struct ceph_auth_handshake.  These\ncached values are then used by the messenger connect code when\nsending the authorizer.\n\nceph_x_update_authorizer() can rebuild the authorizer when a newer\nservice ticket is available.  If the rebuilt authorizer no longer\nfits in the existing buffer, ceph_x_build_authorizer() drops its\nreference to au-\u0026gt;buf and allocates a new one.  If this is the final\nreference, ceph_buffer_put() frees the old ceph_buffer and its\nvec.iov_base, but auth-\u0026gt;authorizer_buf still points at that freed\nmemory.\n\nA subsequent msgr1 reconnect can therefore queue the stale pointer\nand trigger a KASAN slab-use-after-free in _copy_from_iter() while\ntcp_sendmsg() copies the authorizer.\n\nRefresh auth-\u0026gt;authorizer_buf and auth-\u0026gt;authorizer_buf_len after a\nsuccessful authorizer rebuild so the messenger sends the current\nbuffer.(CVE-2026-68156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/mad: Drop unmatched RMPP responses before reassembly\n\nKernel-handled RMPP receive processing starts reassembly for active\nDATA responses before the response is matched to an outstanding send.\nThe normal match happens later, after ib_process_rmpp_recv_wc() has\neither assembled a complete message or consumed the segment.\n\nThat ordering lets an unsolicited response that routes to a kernel\nRMPP agent by the high TID bits allocate or extend RMPP receive state\nbefore the full TID and source address are checked against a real\nrequest. A reordered burst can therefore reach the receive-side\ninsertion path even though the response would not match any send.\n\nFor kernel-handled RMPP DATA responses, require the existing\nib_find_send_mad() match before entering RMPP reassembly. The matcher\nalready checks the full TID, management class and source address/GID\nagainst the agent wait, backlog and in-flight send lists. If there is\nno match, drop the response without creating RMPP state.\n\nThis leaves the RMPP window behavior unchanged and only rejects\nresponses that have no corresponding request.(CVE-2026-68425)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Copy WQE to local buffer in non-SRQ receive path\n\nFor non-SRQ QPs, the responder reads WQE fields directly from the\nshared queue buffer mapped into userspace. This allows a malicious\nuser to modify fields like num_sge or sge entries while the kernel\nis processing the WQE, leading to out-of-bounds reads in\nrxe_resp_check_length() and copy_data().\n\nIntroduce get_recv_wqe() that validates num_sge and copies the WQE\nto a kernel-local buffer before processing, matching the approach\nalready used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is\nreused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)",
  "id": "OESA-2026-3701",
  "modified": "2026-09-05T15:04:06Z",
  "published": "2026-09-05T15:04:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3701"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47358"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23340"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31668"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52955"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52999"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53131"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53221"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53225"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53228"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64564"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68156"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68425"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74377"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47358",
    "CVE-2026-23340",
    "CVE-2026-31668",
    "CVE-2026-52955",
    "CVE-2026-52999",
    "CVE-2026-53131",
    "CVE-2026-53221",
    "CVE-2026-53225",
    "CVE-2026-53228",
    "CVE-2026-64564",
    "CVE-2026-68156",
    "CVE-2026-68425",
    "CVE-2026-74377"
  ]
}



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.