OESA-2026-2234

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 WRITEONCE() in bpfarchtextpoke() 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 bpfjitbinarypackalloc(). 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 pidx bounds in ext4extcorrectindexes

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

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

Fix this by validating path[k].pidx against EXTLAST_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

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

The fast commit flush path can then pass this jinode to jbd2waitinodedata(), which dereferences ivfsinode->imapping 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 jbd2inode first. Use smpwmb() and WRITEONCE() to publish ei->jinode after initialization. Readers use READONCE() to fetch the pointer.(CVE-2026-31450)

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

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

cgwcsumcrc8rel() correctly computes bounds-safe indices via calcidx():

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 fromidx = toidx = resultidx = -64 on a 64-byte CAN FD frame, calcidx(-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 cgwcsumxorrel() uses from/to/res correctly throughout; fix cgwcsumcrc8rel() to match.

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

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

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

KVM: SEV: Drop WARN on large size for KVMMEMORYENCRYPTREGREGION

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

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

_vmioctl(vm, KVMMEMORYENCRYPTREGREGION, &range);

Note, the checks in sevmemencregisterregion() 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->addr > ULONG_MAX || range->size > 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 CTPTPNUM 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.

ctvmmap() always uses PTEs in vm->ptp[0].area regardless of CTPTPNUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ctvmmap() 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:ctvmmap+0x17c/0x280 [sndctxfi] Call Trace: atcpcmplaybackprepare+0x225/0x3b0 ctpcmplaybackprepare+0x38/0x60 sndpcmdoprepare+0x2f/0x50 sndpcmactionsingle+0x36/0x90 sndpcmactionnonatomic+0xbf/0xd0 sndpcmioctl+0x28/0x40 __x64sysioctl+0x97/0xe0 dosyscall64+0x81/0x610 entrySYSCALL64afterhwframe+0x76/0x7e

Revert CTPTPNUM to 1. The 256 SRCRESOURCENUM 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 afalgget_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget.

afalggetrsgl() currently uses afalgreadable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining afalg_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->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)