{"schema_version":"1.7.2","id":"OESA-2026-3701","modified":"2026-09-05T15:04:06Z","published":"2026-09-05T15:04:06Z","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"],"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\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->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 &\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   <TASK>\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   </TASK>\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->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->alg) is used in the subsequent\nprocessing.\n\nThis patch fixes the issue by adding a check that compares alg and\nb->alg and aborts the processing in case they differ. Furthermore,\nb->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->optp pointer.\n\nIf a fingerprint perfectly matches, the function returns early without\nrestoring ctx->optp to its initial state. If the user has configured\nNF_OSF_LOGLEVEL_ALL, the loop continues to the next fingerprint.\nHowever, because ctx->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->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'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->head` and `skb->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's local address, with any remote address\n  wildcard remote).\n\n- Tunnels matching the packet'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->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->from_addr_param(), which reads the full address (16 bytes for IPv6)\ntrusting the parameter'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("net: sctp: fix KMSAN uninit-value in sctp_inq_pop").(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'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't free the ASCONF's own transport in DEL-IP processing\n\nsctp_process_asconf() caches the transport the ASCONF chunk is processed\nagainst in asconf->transport (== chunk->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'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->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->transport still\npoints at, freeing it (RCU-deferred). The following wildcard DEL-IP then\nreuses the now-dangling asconf->transport in sctp_assoc_set_primary() and\nsctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed\ntransport (->ipaddr, ->state) and plants the dangling pointer into\nasoc->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->authorizer_buf{,_len} after authorizer update\n\nceph_x_create_authorizer() caches au->buf->vec.iov_base and\nau->buf->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->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->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->authorizer_buf and auth->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)","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-2608.6.0.0388.oe2003sp4"}]}],"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"]}}],"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"}],"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}],"database_specific":{"severity":"Critical"}}