{"schema_version":"1.7.2","id":"OESA-2026-2232","modified":"2026-05-09T12:32:29Z","published":"2026-05-09T12:32:29Z","upstream":["CVE-2025-71089","CVE-2026-23442","CVE-2026-31407","CVE-2026-31418","CVE-2026-31420","CVE-2026-31423","CVE-2026-31424","CVE-2026-31602","CVE-2026-31680","CVE-2026-31782"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, a security vulnerability exists in the IOMMU Shared Virtual Addressing (SVA) feature. On x86 architecture when CONFIG_X86 is set, IOMMU hardware caches kernel page table entries. Due to the lack of notification mechanism for kernel page table changes, when kernel page table pages are freed and reused, the IOMMU may retain stale entries, leading to Use-After-Free (UAF) and Write-After-Free (WAF) conditions. This can be exploited to cause arbitrary physical memory DMA access or privilege escalation.(CVE-2025-71089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: add NULL checks for idev in SRv6 paths\n\n__in6_dev_get() can return NULL when the device has no IPv6 configuration\n(e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).\n\nAdd NULL checks for idev returned by __in6_dev_get() in both\nseg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL\npointer dereferences.(CVE-2026-23442)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: add missing netlink policy validations\n\nHyunwoo Kim reports out-of-bounds access in sctp and ctnetlink.\n\nThese attributes are used by the kernel without any validation.\nExtend the netlink policies accordingly.\n\nQuoting the reporter:\n  nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE\n  value directly to ct->proto.sctp.state without checking that it is\n  within the valid range. [..]\n\n  and: ... with exp->dir = 100, the access at\n  ct->master->tuplehash[100] reads 5600 bytes past the start of a\n  320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by\n  UBSAN.(CVE-2026-31407)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: drop logically empty buckets in mtype_del\n\nmtype_del() counts empty slots below n->pos in k, but it only drops the\nbucket when both n->pos and k are zero. This misses buckets whose live\nentries have all been removed while n->pos still points past deleted slots.\n\nTreat a bucket as empty when all positions below n->pos are unused and\nrelease it directly instead of shrinking it further.(CVE-2026-31418)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbridge: mrp: reject zero test interval to avoid OOM panic\n\nbr_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied\ninterval value from netlink without validation. When interval is 0,\nusecs_to_jiffies(0) yields 0, causing the delayed work\n(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule\nitself with zero delay. This creates a tight loop on system_percpu_wq\nthat allocates and transmits MRP test frames at maximum rate, exhausting\nall system memory and causing a kernel panic via OOM deadlock.\n\nThe same zero-interval issue applies to br_mrp_start_in_test_parse()\nfor interconnect test frames.\n\nUse NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both\nIFLA_BRIDGE_MRP_START_TEST_INTERVAL and\nIFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the\nnetlink attribute parsing layer before the value ever reaches the\nworkqueue scheduling code. This is consistent with how other bridge\nsubsystems (br_fdb, br_mst) enforce range constraints on netlink\nattributes.(CVE-2026-31420)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_hfsc: fix divide-by-zero in rtsc_min()\n\nm2sm() converts a u32 slope to a u64 scaled value.  For large inputs\n(e.g. m1=4000000000), the result can reach 2^32.  rtsc_min() stores\nthe difference of two such u64 values in a u32 variable `dsm` and\nuses it as a divisor.  When the difference is exactly 2^32 the\ntruncation yields zero, causing a divide-by-zero oops in the\nconcave-curve intersection path:\n\n  Oops: divide error: 0000\n  RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601)\n  Call Trace:\n   init_ed (net/sched/sch_hfsc.c:629)\n   hfsc_enqueue (net/sched/sch_hfsc.c:1569)\n   [...]\n\nWiden `dsm` to u64 and replace do_div() with div64_u64() so the full\ndifference is preserved.(CVE-2026-31423)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP\n\nWeiming Shi says:\n\nxt_match and xt_target structs registered with NFPROTO_UNSPEC can be\nloaded by any protocol family through nft_compat. When such a\nmatch/target sets .hooks to restrict which hooks it may run on, the\nbitmask uses NF_INET_* constants. This is only correct for families\nwhose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge\nall share the same five hooks (PRE_ROUTING ... POST_ROUTING).\n\nARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different\nsemantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks\nvalidation silently passes for the wrong reasons, allowing matches to\nrun on ARP chains where the hook assumptions (e.g. state->in being\nset on input hooks) do not hold. This leads to NULL pointer\ndereferences; xt_devgroup is one concrete example:\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI\n KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]\n RIP: 0010:devgroup_mt+0xff/0x350\n Call Trace:\n  <TASK>\n  nft_match_eval (net/netfilter/nft_compat.c:407)\n  nft_do_chain (net/netfilter/nf_tables_core.c:285)\n  nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61)\n  nf_hook_slow (net/netfilter/core.c:623)\n  arp_xmit (net/ipv4/arp.c:666)\n  </TASK>\n Kernel panic - not syncing: Fatal exception in interrupt\n\nFix it by restricting arptables to NFPROTO_ARP extensions only.\nNote that arptables-legacy only supports:\n\n- arpt_CLASSIFY\n- arpt_mangle\n- arpt_MARK\n\nthat provide explicit NFPROTO_ARP match/target declarations.(CVE-2026-31424)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ctxfi: Limit PTP to a single page\n\nCommit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256\nplayback streams, but the additional pages are not used by the card\ncorrectly. The CT20K2 hardware already has multiple VMEM_PTPAL\nregisters, but using them separately would require refactoring the\nentire virtual memory allocation logic.\n\nct_vm_map() always uses PTEs in vm->ptp[0].area regardless of\nCT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When\naggregate memory allocations exceed this limit, ct_vm_map() tries to\naccess beyond the allocated space and causes a page fault:\n\n  BUG: unable to handle page fault for address: ffffd4ae8a10a000\n  Oops: Oops: 0002 [#1] SMP PTI\n  RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi]\n  Call Trace:\n  atc_pcm_playback_prepare+0x225/0x3b0\n  ct_pcm_playback_prepare+0x38/0x60\n  snd_pcm_do_prepare+0x2f/0x50\n  snd_pcm_action_single+0x36/0x90\n  snd_pcm_action_nonatomic+0xbf/0xd0\n  snd_pcm_ioctl+0x28/0x40\n  __x64_sys_ioctl+0x97/0xe0\n  do_syscall_64+0x81/0x610\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nRevert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count\nremain unchanged.(CVE-2026-31602)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: flowlabel: defer exclusive option free until RCU teardown\n\n`ip6fl_seq_show()` walks the global flowlabel hash under the seq-file\nRCU read-side lock and prints `fl->opt->opt_nflen` when an option block\nis present.\n\nExclusive flowlabels currently free `fl->opt` as soon as `fl->users`\ndrops to zero in `fl_release()`. However, the surrounding\n`struct ip6_flowlabel` remains visible in the global hash table until\nlater garbage collection removes it and `fl_free_rcu()` finally tears it\ndown.\n\nA concurrent `/proc/net/ip6_flowlabel` reader can therefore race that\nearly `kfree()` and dereference freed option state, triggering a crash\nin `ip6fl_seq_show()`.\n\nFix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches\nthe lifetime already required for the enclosing flowlabel while readers\ncan still reach it under RCU.(CVE-2026-31680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86: Fix potential bad container_of in intel_pmu_hw_config\n\nAuto counter reload may have a group of events with software events\npresent within it. The software event PMU isn't the x86_hybrid_pmu and\na container_of operation in intel_pmu_set_acr_caused_constr (via the\nhybrid helper) could cause out of bound memory reads. Avoid this by\nguarding the call to intel_pmu_set_acr_caused_constr with an\nis_x86_event check.(CVE-2026-31782)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP3","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.0.9.140.oe2403sp3"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","bpftool-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","kernel-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","kernel-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","kernel-debugsource-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","kernel-devel-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","kernel-extra-modules-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","kernel-headers-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","kernel-source-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","kernel-tools-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","kernel-tools-devel-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","perf-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","perf-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","python3-perf-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm"],"src":["kernel-6.6.0-145.0.9.140.oe2403sp3.src.rpm"],"x86_64":["bpftool-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","bpftool-debuginfo-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","kernel-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","kernel-debuginfo-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","kernel-debugsource-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","kernel-devel-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","kernel-extra-modules-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","kernel-headers-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","kernel-source-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","kernel-tools-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","kernel-tools-devel-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","perf-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","perf-debuginfo-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","python3-perf-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2232"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71089"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23442"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31407"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31418"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31420"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31423"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31424"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31602"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31680"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31782"}],"database_specific":{"severity":"High"}}