GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2026-2234 (CVE-2026-23383)

Vulnerability from osv_openeuler – Published: 2026-05-09 11:11 – Updated: 2026-08-06 11:11 – Source website
VLAI
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing

struct bpf_plt contains a u64 target field. Currently, the BPF JIT allocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT buffer.

Because the base address of the JIT buffer can be 4-byte aligned (e.g., ending in 0x4 or 0xc), the relative padding logic in build_plt() fails to ensure that target lands on an 8-byte boundary.

This leads to two issues: 1. UBSAN reports misaligned-access warnings when dereferencing the structure. 2. More critically, target is updated concurrently via WRITE_ONCE() in bpf_arch_text_poke() while the JIT'd code executes ldr. On arm64, 64-bit loads/stores are only guaranteed to be single-copy atomic if they are 64-bit aligned. A misaligned target risks a torn read, causing the JIT to jump to a corrupted address.

Fix this by increasing the allocation alignment requirement to 8 bytes (sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base of the JIT buffer to an 8-byte boundary, allowing the relative padding math in build_plt() to correctly align the target field.(CVE-2026-23383)

In the Linux kernel, the following vulnerability has been resolved:

ext4: validate p_idx bounds in ext4_ext_correct_indexes

ext4_ext_correct_indexes() walks up the extent tree correcting index entries when the first extent in a leaf is modified. Before accessing path[k].p_idx->ei_block, there is no validation that p_idx falls within the valid range of index entries for that level.

If the on-disk extent header contains a corrupted or crafted eh_entries value, p_idx can point past the end of the allocated buffer, causing a slab-out-of-bounds read.

Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at both access sites: before the while loop and inside it. Return -EFSCORRUPTED if the index pointer is out of range, consistent with how other bounds violations are handled in the ext4 extent tree code.(CVE-2026-31449)

In the Linux kernel, the following vulnerability has been resolved:

ext4: publish jinode after initialization

ext4_inode_attach_jinode() publishes ei->jinode to concurrent users. It used to set ei->jinode before jbd2_journal_init_jbd_inode(), allowing a reader to observe a non-NULL jinode with i_vfs_inode still unset.

The fast commit flush path can then pass this jinode to jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and may crash.

Below is the crash I observe:

BUG: unable to handle page fault for address: 000000010beb47f4
PGD 110e51067 P4D 110e51067 PUD 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014
RIP: 0010:xas_find_marked+0x3d/0x2e0
Code: 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
RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246
RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003
RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10
RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec
R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000
R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88
FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
<TASK>
filemap_get_folios_tag+0x87/0x2a0
__filemap_fdatawait_range+0x5f/0xd0
? srso_alias_return_thunk+0x5/0xfbef5
? __schedule+0x3e7/0x10c0
? srso_alias_return_thunk+0x5/0xfbef5
? srso_alias_return_thunk+0x5/0xfbef5
? srso_alias_return_thunk+0x5/0xfbef5
? preempt_count_sub+0x5f/0x80
? srso_alias_return_thunk+0x5/0xfbef5
? cap_safe_nice+0x37/0x70
? srso_alias_return_thunk+0x5/0xfbef5
? preempt_count_sub+0x5f/0x80
? srso_alias_return_thunk+0x5/0xfbef5
filemap_fdatawait_range_keep_errors+0x12/0x40
ext4_fc_commit+0x697/0x8b0
? ext4_file_write_iter+0x64b/0x950
? srso_alias_return_thunk+0x5/0xfbef5
? preempt_count_sub+0x5f/0x80
? srso_alias_return_thunk+0x5/0xfbef5
? vfs_write+0x356/0x480
? srso_alias_return_thunk+0x5/0xfbef5
? preempt_count_sub+0x5f/0x80
ext4_sync_file+0xf7/0x370
do_fsync+0x3b/0x80
? syscall_trace_enter+0x108/0x1d0
__x64_sys_fdatasync+0x16/0x20
do_syscall_64+0x62/0x2c0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
...

Fix this by initializing the jbd2_inode first. Use smp_wmb() and WRITE_ONCE() to publish ei->jinode after initialization. Readers use READ_ONCE() to fetch the pointer.(CVE-2026-31450)

In the Linux kernel, the following vulnerability has been resolved:

can: gw: fix OOB heap access in cgw_csum_crc8_rel()

cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():

int from = calc_idx(crc8->from_idx, cf->len);
int to   = calc_idx(crc8->to_idx,   cf->len);
int res  = calc_idx(crc8->result_idx, cf->len);

if (from < 0 || to < 0 || res < 0)
    return;

However, the loop and the result write then use the raw s8 fields directly instead of the computed variables:

for (i = crc8->from_idx; ...)        /* BUG: raw negative index */
cf->data[crc8->result_idx] = ...;    /* BUG: raw negative index */

With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame, calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf->data[-64], and the write goes to cf->data[-64]. This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before the start of the canfd_frame on the heap.

The companion function cgw_csum_xor_rel() uses from/to/res correctly throughout; fix cgw_csum_crc8_rel() to match.

Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62

To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.(CVE-2026-31570)

In the Linux kernel, the following vulnerability has been resolved:

KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION

Drop the WARN in sev_pin_memory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing:

struct kvm_enc_region range = { .addr = 0, .size = -1ul, };

__vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range);

Note, the checks in sev_mem_enc_register_region() that presumably exist to verify the incoming address+size are completely worthless, as both "addr" and "size" are u64s and SEV is 64-bit only, i.e. they can't be greater than ULONG_MAX. That wart will be cleaned up in the near future.

if (range-&gt;addr &gt; ULONG_MAX || range-&gt;size &gt; ULONG_MAX)
    return -EINVAL;

Opportunistically add a comment to explain why the code calculates the number of pages the "hard" way, e.g. instead of just shifting @ulen.(CVE-2026-31590)

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:

crypto: af_alg - limit RX SG extraction by receive buffer budget

Make af_alg_get_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget.

af_alg_get_rsgl() currently uses af_alg_readable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining af_alg_rcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request.

If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero.(CVE-2026-31677)

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-&gt;opt-&gt;opt_nflen when an option block is present.

Exclusive flowlabels currently free fl-&gt;opt as soon as fl-&gt;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-&gt;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)

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "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"
        ],
        "src": [
          "kernel-5.10.0-313.0.0.216.oe2203sp4.src.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"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-313.0.0.216.oe2203sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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\u0026apos;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-\u0026gt;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-\u0026gt;jinode to concurrent users.\nIt used to set ei-\u0026gt;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-\u0026gt;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 \u0026lt;49\u0026gt; 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\u0026lt;TASK\u0026gt;\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-\u0026gt;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-\u0026gt;from_idx, cf-\u0026gt;len);\n    int to   = calc_idx(crc8-\u0026gt;to_idx,   cf-\u0026gt;len);\n    int res  = calc_idx(crc8-\u0026gt;result_idx, cf-\u0026gt;len);\n\n    if (from \u0026lt; 0 || to \u0026lt; 0 || res \u0026lt; 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-\u0026gt;from_idx; ...)        /* BUG: raw negative index */\n    cf-\u0026gt;data[crc8-\u0026gt;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-\u0026gt;data[-64], and the write goes to cf-\u0026gt;data[-64].\nThis write might end up to 56 (7.0-rc) or 40 (\u0026lt;= 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, \u0026amp;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 \u0026quot;addr\u0026quot;\nand \u0026quot;size\u0026quot; are u64s and SEV is 64-bit only, i.e. they _can\u0026apos;t_ be greater\nthan ULONG_MAX.  That wart will be cleaned up in the near future.\n\n\tif (range-\u0026gt;addr \u0026gt; ULONG_MAX || range-\u0026gt;size \u0026gt; ULONG_MAX)\n\t\treturn -EINVAL;\n\nOpportunistically add a comment to explain why the code calculates the\nnumber of pages the \u0026quot;hard\u0026quot; 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-\u0026gt;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-\u0026gt;opt-\u0026gt;opt_nflen` when an option block\nis present.\n\nExclusive flowlabels currently free `fl-\u0026gt;opt` as soon as `fl-\u0026gt;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-\u0026gt;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)",
  "id": "OESA-2026-2234",
  "modified": "2026-08-06T11:11:12Z",
  "published": "2026-05-09T11:11:12Z",
  "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"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "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"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.