OESA-2026-3156

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

drbd: add missing krefget in handlewrite_conflicts

With two-primaries enabled, DRBD tries to detect "concurrent" writes and handle write conflicts, so that even if you write to the same sector simultaneously on both nodes, they end up with the identical data once the writes are completed.

In handling "superseeded" writes, we forgot a krefget, resulting in a premature drbddestroy_device and use after free, and further to kernel crashes with symptoms.

Relevance: No one should use DRBD as a random data generator, and apparently all users of "two-primaries" handle concurrent writes correctly on layer up. That is cluster file systems use some distributed lock manager, and live migration in virtualization environments stops writes on one node before starting writes on the other node.

Which means that other than for "test cases", this code path is never taken in real life.

FYI, in DRBD 9, things are handled differently nowadays. We still detect "write conflicts", but no longer try to be smart about them. We decided to disconnect hard instead: upper layers must not submit concurrent writes. If they do, that's their fault.(CVE-2025-38708)

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

wifi: mwifiex: Initialize the chan_stats array to zero

The adapter->chanstats[] array is initialized in mwifiexinitchannelscangap() with vmalloc(), which doesn't zero out memory. The array is filled in mwifiexupdatechanstatistics() and then the user can query the data in mwifiexcfg80211dump_survey().

There are two potential issues here. What if the user calls mwifiexcfg80211dumpsurvey() before the data has been filled in. Also the mwifiexupdatechanstatistics() function doesn't necessarily initialize the whole array. Since the array was not initialized at the start that could result in an information leak.

Also this array is pretty small. It's a maximum of 900 bytes so it's more appropriate to use kcalloc() instead vmalloc().(CVE-2025-39891)

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

ALSA: ctxfi: Fix potential OOB access in audio mixer handling

In the audio mixer handling code of ctxfi driver, the conf field is used as a kind of loop index, and it's referred in the index callbacks (amixerindex() and sumindex()).

As spotted recently by fuzzers, the current code causes OOB access at those functions. | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | index 8 is out of range for type 'unsigned char [8]'

After the analysis, the cause was found to be the lack of the proper (re-)initialization of conj field.

This patch addresses those OOB accesses by adding the proper initializations of the loop indices.(CVE-2026-23076)

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

rxrpc: Fix call removal to use RCU safe deletion

Fix rxrpc call removal from the rxnet->calls list to use listdelrcu() rather than listdelinit() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop.

This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by:

Firstly, make rxrpcdestroyallcalls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call condresched() or to remove calls from the list here, thereby eliminating the need for rxrpcputcall() to check for that.

rxrpcputcall() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs.(CVE-2026-31642)

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

drm/exynos: vidi: use priv->vididev for ctx lookup in vidiconnection_ioctl()

vidiconnectionioctl() retrieves the driverdata from drmdev->dev to obtain a struct vidicontext pointer. However, drmdev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device.

This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more.

To resolve this issue, we need to store/delete the vidi device pointer in exynosdrmprivate->vididev during bind/unbind, and then read this exynosdrmprivate->vididev within ioctl() to obtain the correct struct vidi_context pointer.(CVE-2026-45956)

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

apparmor: fix invalid deref of rawdata when export_binary is unset

If the export_binary parameter is disabled on runtime, profiles that were loaded before that will still have their rawdata stored in apparmorfs, with a symbolic link to the rawdata on the policy directory. When one of those profiles are replaced, the rawdata is set to NULL, but when trying to resolve the symbolic links to rawdata for that profile, it will try to dereference profile->rawdata->name when profile->rawdata is now NULL causing an oops. Fix it by checking if rawdata is set.

[ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088 [ 168.657420] #PF: supervisor read access in kernel mode [ 168.660619] #PF: errorcode(0x0000) - not-present page [ 168.663613] PGD 0 P4D 0 [ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI [ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary) [ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP: 0010:rawdatagetlinkbase.isra.0+0x23/0x330 [ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8 [ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282 [ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158 [ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80 [ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000 [ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80 [ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0 [ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000 [ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0 [ 168.701696] Call Trace: [ 168.702325] <TASK> [ 168.702995] rawdatagetlinkdata+0x1c/0x30 [ 168.704145] vfsreadlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64sysreadlink+0x1e/0x30 [ 168.708653] x64syscall+0x1d77/0x26b0 [ 168.709525] dosyscall64+0x81/0x500 [ 168.710348] ? do_statx+0x72/0xb0 [ 168.711109] ? putname+0x3e/0x80 [ 168.711845] ? __x64sysstatx+0xb7/0x100 [ 168.712711] ? x64syscall+0x10fc/0x26b0 [ 168.713577] ? dosyscall64+0xbf/0x500 [ 168.714412] ? douseraddrfault+0x1d2/0x8d0 [ 168.715404] ? irqentryexit+0xb2/0x740 [ 168.716359] ? excpagefault+0x90/0x1b0 [ 168.717307] entrySYSCALL64afterhwframe+0x76/0x7e(CVE-2026-45965)

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

LoongArch: Add spectre boundry for syscall dispatch table

The LoongArch syscall number is directly controlled by userspace, but does not have a arrayindexnospec() boundry to prevent access past the syscall function pointer tables.(CVE-2026-45993)

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

mptcp: pm: ADD_ADDR rtx: fix potential data-race

This mptcppmaddtimer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bhlock_sock().

If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.(CVE-2026-46137)

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

hfsplus: fix uninit-value by validating catalog record size

Syzbot reported a KMSAN uninit-value issue in hfsplusstrcasecmp(). The root cause is that hfsbrec_read() doesn't validate that the on-disk record size matches the expected size for the record type being read.

When mounting a corrupted filesystem, hfsbrecread() may read less data than expected. For example, when reading a catalog thread record, the debug output showed:

HFSPLUSBRECREAD: reclen=520, fd->entrylength=26 HFSPLUSBRECREAD: WARNING - entrylength (26) < reclen (520) - PARTIAL READ!

hfsbrecread() only validates that entrylength is not greater than the buffer size, but doesn't check if it's less than expected. It successfully reads 26 bytes into a 520-byte structure and returns success, leaving 494 bytes uninitialized.

This uninitialized data in tmp.thread.nodeName then gets copied by hfspluscatbuildkeyuni() and used by hfsplusstrcasecmp(), triggering the KMSAN warning when the uninitialized bytes are used as array indices in casefold().

Fix by introducing hfsplusbrecreadcat() wrapper that: 1. Calls hfsbrec_read() to read the data 2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length) 3. Returns -EIO if size doesn't match expected

For thread records, check against HFSPLUSMINTHREAD_SZ before reading nodeName.length to avoid reading uninitialized data at call sites that don't zero-initialize the entry structure.

Also initialize the tmp variable in hfsplusfindcat() as defensive programming to ensure no uninitialized data even if validation is bypassed.(CVE-2026-46169)

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

isofs: validate Rock Ridge CE continuation extent against volume size

rockcontinue() reads rs->contextent verbatim from the Rock Ridge CE record and passes it to sbbread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b ("[PATCH] rock.c: handle corrupted directories") added contoffset and contsize rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 ("isofs: Fix infinite looping over CE entries") later capped the CE chain length at RRMAXCEENTRIES = 32 but again left the block number unchecked.

With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAPSYSADMIN mount, rs->contextent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sbbread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for contoffset and contsize.

Add an ISOFSSB(sb)->snzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.(CVE-2026-46303)

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

neigh: let neigh_xmit take skb ownership

neighxmit always releases the skb, except when no neighbour table is found. But even the first added user of neighxmit (mpls) relied on neigh_xmit to release the skb (or queue it for tx).

sashiko reported: If neighxmit() is called with an uninitialized neighbor table (for example, NEIGHNDTABLE when IPv6 is disabled), it returns -EAFNOSUPPORT and bypasses its internal outkfreeskb error path. Because the return value of neighxmit() is ignored here, does this leak the SKB?

Assume full ownership and remove the last code path that doesn't xmit or free skb.(CVE-2026-52981)

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

sctp: fix OOB write to userspace in sctpgetsockoptpeerauthchunks

sctpgetsockoptpeerauthchunks() checks that the caller's optval buffer is large enough for the peer AUTH chunk list with

if (len < num_chunks)
        return -EINVAL;

but then writes numchunks bytes to p->gauthchunks, which lives at offset offsetof(struct sctpauthchunks, gauthchunks) == 8 inside optval. The check is missing the sizeof(struct sctpauthchunks) = 8-byte header. When the caller supplies len == numchunks (for any numchunks > 0) the test passes but copytouser() writes sizeof(struct sctpauthchunks) = 8 bytes past the declared buffer.

The sibling function sctpgetsockoptlocalauthchunks() at the next line already has the correct check:

if (len < sizeof(struct sctp_authchunks) + num_chunks)
        return -EINVAL;

Align the peer variant with its sibling.

Reproducer confirms on v7.0-13-generic: an unprivileged userspace caller that opens a loopback SCTP association with AUTH enabled, queries numchunks with a short optval, then issues the real getsockopt with len == numchunks and sentinel bytes painted past the buffer observes those sentinel bytes overwritten with the peer's AUTH chunk type. The bytes written are under the peer's control but land in the caller's own userspace; this is not a kernel memory corruption, but it is a kernel-side contract violation that can silently corrupt adjacent userspace data.(CVE-2026-53004)

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

ice: fix double-free of tx_buf skb

If icetso() or icetxcsum() fail, the error path in icexmitframering() frees the skb, but the 'first' txbuf still points to it and is marked as valid (ICETXBUFSKB). 'nexttouse' remains unchanged, so the potential problem will likely fix itself when the next packet is transmitted and the txbuf gets overwritten. But if there is no next packet and the interface is brought down instead, icecleantxring() -> iceunmapandfreetxbuf() will find the txbuf and free the skb for the second time.

The fix is to reset the txbuf type to ICETXBUFEMPTY in the error path, so that iceunmapandfreetx_buf(). Move the initialization of 'first' up, to ensure it's already valid in case we hit the linearization error path.

The bug was spotted by AI while I had it looking for something else. It also proposed an initial version of the patch.

I reproduced the bug and tested the fix by adding code to inject failures, on a build with KASAN.

I looked for similar bugs in related Intel drivers and did not find any.(CVE-2026-53009)

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

bpf, arm64: Fix off-by-one in check_imm signed range check

check_imm(bits, imm) is used in the arm64 BPF JIT to verify that a branch displacement (in arm64 instruction units) fits into the signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding before it is handed to the encoder. The macro currently tests for (imm > 0 && imm >> bits) || (imm < 0 && ~imm >> bits) which admits values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check admits one extra bit of range on each side.

In particular, for checkimm19(), values in [2^18, 2^19) slip past the check but do not fit into the 19-bit signed imm19 field of B.cond. aarch64insnencodeimmediate() then masks the raw value into the 19-bit field, setting bit 18 (the sign bit) and flipping a forward branch into a backward one. Same class of issue exists for check_imm26() and the B/BL encoding. Shift by (bits - 1) instead of bits so the actual signed N-bit range is enforced.(CVE-2026-53036)

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

ocfs2: validate bg_bits during freefrag scan

[BUG] A crafted filesystem can trigger an out-of-bounds bitmap walk when OCFS2IOCINFO is issued with OCFS2INFOFLNONCOHERENT.

BUG: KASAN: use-after-free in instrumentatomicread include/linux/instrumented.h:68 [inline] BUG: KASAN: use-after-free in testbit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: use-after-free in testbitle include/asm-generic/bitops/le.h:21 [inline] BUG: KASAN: use-after-free in ocfs2infofreefragscanchain fs/ocfs2/ioctl.c:495 [inline] BUG: KASAN: use-after-free in ocfs2infofreefragscanbitmap fs/ocfs2/ioctl.c:588 [inline] BUG: KASAN: use-after-free in ocfs2infohandlefreefrag fs/ocfs2/ioctl.c:662 [inline] BUG: KASAN: use-after-free in ocfs2infohandlerequest+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 Read of size 8 at addr ffff888031bce000 by task syz.0.636/1435 Call Trace: __dumpstack lib/dumpstack.c:94 [inline] dump_stacklvl+0xbe/0x130 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xd1/0x650 mm/kasan/report.c:482 kasanreport+0xfb/0x140 mm/kasan/report.c:595 checkregioninline mm/kasan/generic.c:186 [inline] kasancheckrange+0x11c/0x200 mm/kasan/generic.c:200 __kasancheckread+0x11/0x20 mm/kasan/shadow.c:31 instrumentatomicread include/linux/instrumented.h:68 [inline] testbit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] testbitle include/asm-generic/bitops/le.h:21 [inline] ocfs2infofreefragscanchain fs/ocfs2/ioctl.c:495 [inline] ocfs2infofreefragscanbitmap fs/ocfs2/ioctl.c:588 [inline] ocfs2infohandlefreefrag fs/ocfs2/ioctl.c:662 [inline] ocfs2infohandlerequest+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 ocfs2infohandle+0x18d/0x2a0 fs/ocfs2/ioctl.c:828 ocfs2ioctl+0x632/0x6e0 fs/ocfs2/ioctl.c:913 vfsioctl fs/ioctl.c:51 [inline] __dosysioctl fs/ioctl.c:597 [inline] __sesysioctl fs/ioctl.c:583 [inline] __x64sysioctl+0x197/0x1e0 fs/ioctl.c:583 ...

[CAUSE] ocfs2infofreefragscanchain() uses on-disk bgbits directly as the bitmap scan limit. The coherent path reads group descriptors through ocfs2readgroupdescriptor(), which validates the descriptor before use. The non-coherent path uses ocfs2readblockssync() instead and skips that validation, so an impossible bgbits value can drive the bitmap walk past the end of the block.

[FIX] Compute the bitmap capacity from the filesystem format with ocfs2groupbitmapsize(), report descriptors whose bgbits exceeds that limit, and clamp the scan to the computed capacity. This keeps the freefrag report going while avoiding reads beyond the buffer.(CVE-2026-53040)

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

drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs

[Why & How] dpsdpmessagedebugfswrite() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node.

The function also ignores the user-provided size argument and always passes 36 bytes to copyfromuser(), reading past the user buffer when size < 36.

Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data))

(cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)(CVE-2026-53135)

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

IB/isert: Reject login PDUs shorter than ISERHEADERSLEN

In drivers/infiniband/ulp/isert/ibisert.c, isertloginrecvdone() computes the login request payload length as wc->bytelen minus ISERHEADERSLEN with no lower bound, and loginreqlen is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISERHEADERSLEN (76) bytes, so the subtraction underflows and loginreq_len becomes negative.

isertrxloginreq() then reads that negative length back into a signed int, takes size = min(rxbuflen, MAXKEYVALUEPAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte sizet. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path.

Reject any login PDU shorter than ISERHEADERSLEN before the subtraction, mirroring the existing early return on a failed work completion, so loginreqlen can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISERRXPAYLOADSIZE, so the difference stays at or below MAXKEYVALUEPAIRS and the existing min() clamps it; only the missing lower bound needs to be added.(CVE-2026-53176)