{"schema_version":"1.7.2","id":"OESA-2026-2236","modified":"2026-05-09T12:32:43Z","published":"2026-05-09T12:32:43Z","upstream":["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, 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-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.0.9.148.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm","kernel-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm","perf-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.0.9.148.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-145.0.9.148.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm","kernel-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm","perf-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.0.9.148.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2236"},{"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"}}