{"id":"OESA-2026-2234","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\nbpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing\n\nstruct bpf_plt contains a u64 target field. Currently, the BPF JIT\nallocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT\nbuffer.\n\nBecause the base address of the JIT buffer can be 4-byte aligned (e.g.,\nending in 0x4 or 0xc), the relative padding logic in build_plt() fails\nto ensure that target lands on an 8-byte boundary.\n\nThis leads to two issues:\n1. UBSAN reports misaligned-access warnings when dereferencing the\n   structure.\n2. More critically, target is updated concurrently via WRITE_ONCE() in\n   bpf_arch_text_poke() while the JIT'd code executes ldr. On arm64,\n   64-bit loads/stores are only guaranteed to be single-copy atomic if\n   they are 64-bit aligned. A misaligned target risks a torn read,\n   causing the JIT to jump to a corrupted address.\n\nFix this by increasing the allocation alignment requirement to 8 bytes\n(sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base of\nthe JIT buffer to an 8-byte boundary, allowing the relative padding math\nin build_plt() to correctly align the target field.(CVE-2026-23383)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: validate p_idx bounds in ext4_ext_correct_indexes\n\next4_ext_correct_indexes() walks up the extent tree correcting\nindex entries when the first extent in a leaf is modified. Before\naccessing path[k].p_idx->ei_block, there is no validation that\np_idx falls within the valid range of index entries for that\nlevel.\n\nIf the on-disk extent header contains a corrupted or crafted\neh_entries value, p_idx can point past the end of the allocated\nbuffer, causing a slab-out-of-bounds read.\n\nFix this by validating path[k].p_idx against EXT_LAST_INDEX() at\nboth access sites: before the while loop and inside it. Return\n-EFSCORRUPTED if the index pointer is out of range, consistent\nwith how other bounds violations are handled in the ext4 extent\ntree code.(CVE-2026-31449)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: publish jinode after initialization\n\next4_inode_attach_jinode() publishes ei->jinode to concurrent users.\nIt used to set ei->jinode before jbd2_journal_init_jbd_inode(),\nallowing a reader to observe a non-NULL jinode with i_vfs_inode\nstill unset.\n\nThe fast commit flush path can then pass this jinode to\njbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and\nmay crash.\n\nBelow is the crash I observe:\n```\nBUG: unable to handle page fault for address: 000000010beb47f4\nPGD 110e51067 P4D 110e51067 PUD 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014\nRIP: 0010:xas_find_marked+0x3d/0x2e0\nCode: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02\nRSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246\nRAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003\nRDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10\nRBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec\nR10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000\nR13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88\nFS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n<TASK>\nfilemap_get_folios_tag+0x87/0x2a0\n__filemap_fdatawait_range+0x5f/0xd0\n? srso_alias_return_thunk+0x5/0xfbef5\n? __schedule+0x3e7/0x10c0\n? srso_alias_return_thunk+0x5/0xfbef5\n? srso_alias_return_thunk+0x5/0xfbef5\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\n? srso_alias_return_thunk+0x5/0xfbef5\n? cap_safe_nice+0x37/0x70\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\n? srso_alias_return_thunk+0x5/0xfbef5\nfilemap_fdatawait_range_keep_errors+0x12/0x40\next4_fc_commit+0x697/0x8b0\n? ext4_file_write_iter+0x64b/0x950\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\n? srso_alias_return_thunk+0x5/0xfbef5\n? vfs_write+0x356/0x480\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\next4_sync_file+0xf7/0x370\ndo_fsync+0x3b/0x80\n? syscall_trace_enter+0x108/0x1d0\n__x64_sys_fdatasync+0x16/0x20\ndo_syscall_64+0x62/0x2c0\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n...\n```\n\nFix this by initializing the jbd2_inode first.\nUse smp_wmb() and WRITE_ONCE() to publish ei->jinode after\ninitialization. Readers use READ_ONCE() to fetch the pointer.(CVE-2026-31450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: gw: fix OOB heap access in cgw_csum_crc8_rel()\n\ncgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():\n\n    int from = calc_idx(crc8->from_idx, cf->len);\n    int to   = calc_idx(crc8->to_idx,   cf->len);\n    int res  = calc_idx(crc8->result_idx, cf->len);\n\n    if (from < 0 || to < 0 || res < 0)\n        return;\n\nHowever, the loop and the result write then use the raw s8 fields directly\ninstead of the computed variables:\n\n    for (i = crc8->from_idx; ...)        /* BUG: raw negative index */\n    cf->data[crc8->result_idx] = ...;    /* BUG: raw negative index */\n\nWith from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame,\ncalc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with\ni = -64, reading cf->data[-64], and the write goes to cf->data[-64].\nThis write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before the\nstart of the canfd_frame on the heap.\n\nThe companion function cgw_csum_xor_rel() uses `from`/`to`/`res`\ncorrectly throughout; fix cgw_csum_crc8_rel() to match.\n\nConfirmed with KASAN on linux-7.0-rc2:\n  BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0\n  Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62\n\nTo configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.(CVE-2026-31570)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION\n\nDrop the WARN in sev_pin_memory() on npages overflowing an int, as the\nWARN is comically trivially to trigger from userspace, e.g. by doing:\n\n  struct kvm_enc_region range = {\n          .addr = 0,\n          .size = -1ul,\n  };\n\n  __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range);\n\nNote, the checks in sev_mem_enc_register_region() that presumably exist to\nverify the incoming address+size are completely worthless, as both "addr"\nand "size" are u64s and SEV is 64-bit only, i.e. they _can't_ be greater\nthan ULONG_MAX.  That wart will be cleaned up in the near future.\n\n\tif (range->addr > ULONG_MAX || range->size > ULONG_MAX)\n\t\treturn -EINVAL;\n\nOpportunistically add a comment to explain why the code calculates the\nnumber of pages the "hard" way, e.g. instead of just shifting @ulen.(CVE-2026-31590)\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\ncrypto: af_alg - limit RX SG extraction by receive buffer budget\n\nMake af_alg_get_rsgl() limit each RX scatterlist extraction to the\nremaining receive buffer budget.\n\naf_alg_get_rsgl() currently uses af_alg_readable() only as a gate\nbefore extracting data into the RX scatterlist. Limit each extraction\nto the remaining af_alg_rcvbuf(sk) budget so that receive-side\naccounting matches the amount of data attached to the request.\n\nIf skcipher cannot obtain enough RX space for at least one chunk while\nmore data remains to be processed, reject the recvmsg call instead of\nrounding the request length down to zero.(CVE-2026-31677)\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)","modified":"2026-05-09T12:49:59.055939Z","published":"2026-05-09T12:32:34Z","upstream":["CVE-2026-23383","CVE-2026-31449","CVE-2026-31450","CVE-2026-31570","CVE-2026-31590","CVE-2026-31602","CVE-2026-31677","CVE-2026-31680"],"database_specific":{"severity":"High"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2234"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23383"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31449"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31450"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31570"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31590"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31602"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31677"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31680"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:22.03-LTS-SP4","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-313.0.0.216.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm","kernel-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm","perf-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-313.0.0.216.oe2203sp4.aarch64.rpm"],"x86_64":["bpftool-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm","kernel-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm","perf-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-313.0.0.216.oe2203sp4.x86_64.rpm"],"src":["kernel-5.10.0-313.0.0.216.oe2203sp4.src.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-2234.json"}}],"schema_version":"1.7.5"}