{"schema_version":"1.7.2","id":"OESA-2026-4038","modified":"2026-09-25T01:27:34Z","published":"2026-09-25T01:27:34Z","upstream":["CVE-2026-52924","CVE-2026-72322","CVE-2026-74398","CVE-2026-74597","CVE-2026-74662","CVE-2026-74743","CVE-2026-74744","CVE-2026-80737","CVE-2026-89729"],"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\nsctp: purge outqueue on stale COOKIE-ECHO handling\n\nsctp_stream_update() is only invoked when the association is moved into\nCOOKIE_WAIT during association setup/reconfiguration. In this path, the\noutbound stream scheduler state (stream->out_curr) is expected to be\nclean, since no user data should have been transmitted yet unless the\nstate machine has already partially progressed.\n\nHowever, a corner case exists in sctp_sf_do_5_2_6_stale(): when a\nStale Cookie ERROR is received, the association is rolled back from\nCOOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already\nhave been queued and even bundled with the COOKIE-ECHO chunk.\n\nDuring the rollback, sctp_stream_update() frees the old stream table\nand installs a new one, but it does not invalidate stream->out_curr.\nAs a result, out_curr may still point to a freed sctp_stream_out\nentry from the previous stream state.\n\nLater, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on\nstream->out_curr->ext, which can lead to use-after-free once the old\nstream state has been released via sctp_stream_free().\n\nThis results in crashes such as (reported by Yuqi):\n\n  BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140\n  Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312\n  CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted\n     7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full)\n   sctp_sched_fcfs_dequeue+0x13a/0x140\n   sctp_outq_flush+0x1603/0x33e0\n   sctp_do_sm+0x31c9/0x5d30\n   sctp_assoc_bh_rcv+0x392/0x6f0\n   sctp_inq_push+0x1db/0x270\n   sctp_rcv+0x138d/0x3c10\n\nFix this by fully purging the association outqueue when handling the\nStale Cookie case. This ensures all pending transmit and retransmit\nstate is dropped, and any scheduler cached pointers are invalidated,\nmaking it safe to rebuild stream state during COOKIE_WAIT restart.\n\nUpdating only stream->out_curr would be insufficient, since queued\nand retransmittable data would still reference the old stream state and\ntrigger later use-after-free in dequeue paths.(CVE-2026-52924)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: mcast: Fix potential UAF in MLD delayed work\n\nA race condition exists between device teardown and incoming MLD query\nprocessing, leading to a Use-After-Free in the MLD delayed work.\n\nDuring device destruction, the primary reference to inet6_dev is dropped,\nwhich can drop its refcount to 0. The actual freeing of inet6_dev memory\nis deferred via RCU.\n\nConcurrently, the packet receive path runs under RCU read lock and obtains\nthe inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can\nsafely dereference inet6_dev even if its refcount has hit 0.\n\nHowever, if CPU-0 calls igmp6_event_query() and schedules delayed work, it\nattempts to acquire a reference using in6_dev_hold(). This increments the\nrefcount from 0 to 1, triggering a "refcount_t: addition on 0" warning.\nSince the inet6_dev memory is still scheduled to be freed after the RCU\ngrace period, the device is freed while the work is still scheduled.\nWhen the work runs, it accesses the freed memory, causing a kernel panic.\n\nFix this by using refcount_inc_not_zero() (via a new helper\nin6_dev_hold_safe()) to prevent acquiring a reference if the device is\nalready being destroyed. If the refcount is 0, we do not schedule the work.(CVE-2026-72322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD\n\naddrconf_dad_failure() transitions ifp->state from DAD to POSTDAD\nvia addrconf_dad_end(), which drops ifp->lock on return.  The lock\nis re-acquired after net_info_ratelimited().  A concurrent\nipv6_del_addr() can take the lock in that window, set ifp->state\nto DEAD and run list_del_rcu(&ifp->if_list).\n\naddrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad:\nand schedules a new dad_work.  The work calls ipv6_del_addr()\nagain, hitting the already-poisoned list entry:\n\n  general protection fault: 0000 [#1] SMP NOPTI\n  CPU: 4 PID: 217 Comm: kworker/4:1\n  Workqueue: ipv6_addrconf addrconf_dad_work\n  RIP: 0010:ipv6_del_addr+0xe9/0x280\n  RAX: dead000000000122\n  Call Trace:\n   addrconf_dad_stop+0x113/0x140\n   addrconf_dad_work+0x28c/0x430\n   process_one_work+0x1eb/0x3b0\n   worker_thread+0x4d/0x400\n   kthread+0x104/0x140\n   ret_from_fork+0x35/0x40\n\nFold the addrconf_dad_end() logic into addrconf_dad_failure() under\na single ifp->lock critical section.  The STABLE_PRIVACY branch\ntemporarily drops ifp->lock around address regeneration, so at\nlock_errdad: verify the state is still POSTDAD before transitioning\nto ERRDAD; bail out otherwise to avoid overwriting a state set by\nanother path while the lock was released.(CVE-2026-74398)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6_tunnel: clear skb2->cb[] in ip6ip6_err()\n\nip6ip6_err() clones an outer IPv6 ICMP error skb, pulls it to the\nquoted inner IPv6 packet, and then passes the clone to icmpv6_send().\nThe clone still carries the outer packet's inet6_skb_parm in skb->cb.\n\nIf the outer packet had a Home Address Option, IP6CB(skb2)->dsthao\nremains non-zero after skb_pull(). icmpv6_send() later calls\nmip6_addr_swap(), which uses that stale dsthao offset against the quoted\ninner packet. A malformed inner destination-options header can then make\nthe HAO lookup and address swap run past the end of the quoted packet\nand corrupt skb_shared_info.\n\nClear skb2->cb[] before pulling the quoted inner IPv6 packet so the\nreply path does not reuse metadata left by the outer IPv6 stack.(CVE-2026-74597)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ninet: frags: publish queues before arming timer\n\ninet_frag_create() arms the fragment queue timer before inserting the\nqueue into the fqdir rhashtable. If the namespace fragment timeout is\nzero or negative, the timer can run before the queue is published.\n\nThe timer callback then marks the queue complete, tries to remove a node\nthat is not in the hash table yet, and drops the anticipated hash\nreference. Creation can subsequently publish the completed queue without\nrestoring that reference, leaving a stale hash node after the caller drops\nthe remaining reference.\n\nPublish the queue first and arm the timer while holding the queue lock.\nThis makes timer expiry wait until the queue is visible in the hash table,\nso inet_frag_kill() can remove the node and balance the hash reference.(CVE-2026-74662)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: inherit needed_headroom and needed_tailroom from lowerdev\n\nmacvlan devices inherit hard_header_len from lowerdev during macvlan_init(),\nbut leave needed_headroom and needed_tailroom set to 0.\n\nWhen the underlying lowerdev requires extra headroom or tailroom for\nheaders/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx\nheadroom), upper layers calculating packet headroom and tailroom fail to\nreserve sufficient space.\n\nThis can result in reallocation overhead, skb headroom underflows, or KASAN\nslab-use-after-free crashes when dev_hard_header() / macvlan_hard_header()\nprepends header data or when lower devices append tailroom.\n\nFix this by:\n1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init().\n2. Propagating needed_headroom and needed_tailroom updates to attached macvlans\n   in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.(CVE-2026-74743)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvlan: inherit needed_headroom and needed_tailroom from phy_dev\n\nipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(),\nbut leave needed_headroom and needed_tailroom set to 0.\n\nWhen the underlying phy_dev (or stacked lower device) requires extra headroom\nor tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or\nveth with rx headroom), upper layers calculating packet headroom and tailroom\nfail to reserve sufficient space.\n\nThis can result in reallocation overhead, skb headroom underflows, or KASAN\nslab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header()\nprepends header data or when lower devices append tailroom.\n\nFix this by:\n1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init().\n2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans\n   in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.(CVE-2026-74744)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: amba-pl011: synchronize DMA teardown\n\ndmaengine_terminate_all() does not wait for a running callback, so the TX\ncallback can still touch the TX buffer after it is freed. The RX poll\ntimer reads the RX buffers without the port lock.\n\nSwitch to dmaengine_terminate_sync() and delete the RX timer before\nfreeing the buffers.(CVE-2026-80737)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature\n\nsensor_hub_get_feature() clamps its return value to the caller's buffer\nsize, but the copy loop still copies field->report_size / 8 bytes for\neach report value. A malicious HID descriptor can advertise a large\nfeature field size while an IIO caller supplies a small stack buffer,\nsuch as a single s32, causing an out-of-bounds write.\n\nHID core stores parsed report values in __s32 slots and clamps extracted\nvalues to 32 bits. Reject feature fields that require more than one slot\nper value, guard the total byte count calculation, and clamp each\nper-value copy to the remaining caller buffer.(CVE-2026-89729)","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-2609.3.0.0391.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","kernel-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","perf-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2609.3.0.0391.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","kernel-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","perf-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2609.3.0.0391.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4038"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52924"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72322"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74398"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74597"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74662"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74743"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74744"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80737"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89729"}],"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"}}