An update for kernel is now available for openEuler-24.03-LTS-SP3 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2026-2232 Final 1.0 1.0 2026-05-09 Initial 2026-05-09 2026-05-09 openEuler SA Tool V1.0 2026-05-09 kernel security update An update for kernel is now available for openEuler-24.03-LTS-SP3 The Linux Kernel, the operating system core itself. Security Fix(es): In 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) In the Linux kernel, the following vulnerability has been resolved: ipv6: add NULL checks for idev in SRv6 paths __in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER). Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.(CVE-2026-23442) In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: add missing netlink policy validations Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink. These attributes are used by the kernel without any validation. Extend the netlink policies accordingly. Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN.(CVE-2026-31407) In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.(CVE-2026-31418) In the Linux kernel, the following vulnerability has been resolved: bridge: mrp: reject zero test interval to avoid OOM panic br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock. The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames. Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes.(CVE-2026-31420) In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: fix divide-by-zero in rtsc_min() m2sm() converts a u32 slope to a u64 scaled value. For large inputs (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores the difference of two such u64 values in a u32 variable `dsm` and uses it as a divisor. When the difference is exactly 2^32 the truncation yields zero, causing a divide-by-zero oops in the concave-curve intersection path: Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...] Widen `dsm` to u64 and replace do_div() with div64_u64() so the full difference is preserved.(CVE-2026-31423) In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP Weiming Shi says: xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_* constants. This is only correct for families whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING). ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: <TASK> nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) </TASK> Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports: - arpt_CLASSIFY - arpt_mangle - arpt_MARK that provide explicit NFPROTO_ARP match/target declarations.(CVE-2026-31424) In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Limit PTP to a single page Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic. ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ct_vm_map() tries to access beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count remain unchanged.(CVE-2026-31602) In the Linux kernel, the following vulnerability has been resolved: net: ipv6: flowlabel: defer exclusive option free until RCU teardown `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file RCU read-side lock and prints `fl->opt->opt_nflen` when an option block is present. Exclusive flowlabels currently free `fl->opt` as soon as `fl->users` drops to zero in `fl_release()`. However, the surrounding `struct ip6_flowlabel` remains visible in the global hash table until later garbage collection removes it and `fl_free_rcu()` finally tears it down. A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that early `kfree()` and dereference freed option state, triggering a crash in `ip6fl_seq_show()`. Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU.(CVE-2026-31680) In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix potential bad container_of in intel_pmu_hw_config Auto counter reload may have a group of events with software events present within it. The software event PMU isn't the x86_hybrid_pmu and a container_of operation in intel_pmu_set_acr_caused_constr (via the hybrid helper) could cause out of bound memory reads. Avoid this by guarding the call to intel_pmu_set_acr_caused_constr with an is_x86_event check.(CVE-2026-31782) An update for kernel is now available for openEuler-24.03-LTS-SP3. openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. High kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2232 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-71089 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23442 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-31407 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-31418 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-31420 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-31423 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-31424 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-31602 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-31680 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-31782 https://nvd.nist.gov/vuln/detail/CVE-2025-71089 https://nvd.nist.gov/vuln/detail/CVE-2026-23442 https://nvd.nist.gov/vuln/detail/CVE-2026-31407 https://nvd.nist.gov/vuln/detail/CVE-2026-31418 https://nvd.nist.gov/vuln/detail/CVE-2026-31420 https://nvd.nist.gov/vuln/detail/CVE-2026-31423 https://nvd.nist.gov/vuln/detail/CVE-2026-31424 https://nvd.nist.gov/vuln/detail/CVE-2026-31602 https://nvd.nist.gov/vuln/detail/CVE-2026-31680 https://nvd.nist.gov/vuln/detail/CVE-2026-31782 openEuler-24.03-LTS-SP3 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 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 kernel-6.6.0-145.0.9.140.oe2403sp3.src.rpm In 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. 2026-05-09 CVE-2025-71089 openEuler-24.03-LTS-SP3 High 7.8 AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H kernel security update 2026-05-09 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2232 In the Linux kernel, the following vulnerability has been resolved: ipv6: add NULL checks for idev in SRv6 paths __in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER). Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences. 2026-05-09 CVE-2026-23442 openEuler-24.03-LTS-SP3 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2026-05-09 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2232 In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: add missing netlink policy validations Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink. These attributes are used by the kernel without any validation. Extend the netlink policies accordingly. Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN. 2026-05-09 CVE-2026-31407 openEuler-24.03-LTS-SP3 High 7.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H kernel security update 2026-05-09 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2232 In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further. 2026-05-09 CVE-2026-31418 openEuler-24.03-LTS-SP3 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2026-05-09 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2232 In the Linux kernel, the following vulnerability has been resolved: bridge: mrp: reject zero test interval to avoid OOM panic br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock. The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames. Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes. 2026-05-09 CVE-2026-31420 openEuler-24.03-LTS-SP3 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2026-05-09 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2232 In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: fix divide-by-zero in rtsc_min() m2sm() converts a u32 slope to a u64 scaled value. For large inputs (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores the difference of two such u64 values in a u32 variable `dsm` and uses it as a divisor. When the difference is exactly 2^32 the truncation yields zero, causing a divide-by-zero oops in the concave-curve intersection path: Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...] Widen `dsm` to u64 and replace do_div() with div64_u64() so the full difference is preserved. 2026-05-09 CVE-2026-31423 openEuler-24.03-LTS-SP3 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2026-05-09 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2232 In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP Weiming Shi says: xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_* constants. This is only correct for families whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING). ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: <TASK> nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) </TASK> Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports: - arpt_CLASSIFY - arpt_mangle - arpt_MARK that provide explicit NFPROTO_ARP match/target declarations. 2026-05-09 CVE-2026-31424 openEuler-24.03-LTS-SP3 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2026-05-09 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2232 In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Limit PTP to a single page Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic. ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ct_vm_map() tries to access beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count remain unchanged. 2026-05-09 CVE-2026-31602 openEuler-24.03-LTS-SP3 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2026-05-09 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2232 In the Linux kernel, the following vulnerability has been resolved: net: ipv6: flowlabel: defer exclusive option free until RCU teardown `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file RCU read-side lock and prints `fl->opt->opt_nflen` when an option block is present. Exclusive flowlabels currently free `fl->opt` as soon as `fl->users` drops to zero in `fl_release()`. However, the surrounding `struct ip6_flowlabel` remains visible in the global hash table until later garbage collection removes it and `fl_free_rcu()` finally tears it down. A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that early `kfree()` and dereference freed option state, triggering a crash in `ip6fl_seq_show()`. Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU. 2026-05-09 CVE-2026-31680 openEuler-24.03-LTS-SP3 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2026-05-09 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2232 In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix potential bad container_of in intel_pmu_hw_config Auto counter reload may have a group of events with software events present within it. The software event PMU isn't the x86_hybrid_pmu and a container_of operation in intel_pmu_set_acr_caused_constr (via the hybrid helper) could cause out of bound memory reads. Avoid this by guarding the call to intel_pmu_set_acr_caused_constr with an is_x86_event check. 2026-05-09 CVE-2026-31782 openEuler-24.03-LTS-SP3 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2026-05-09 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2232