OESA-2026-3155

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

iio: accel: bmc150: Fix irq assumption regression

The code in bmc150-accel-core.c unconditionally calls bmc150accelsetinterrupt() in the iiobuffersetupops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts:

Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read

PC is at bmc150accelset_interrupt+0x98/0x194 LR is at __pmruntimeresume+0x5c/0x64 (...) Call trace: bmc150accelsetinterrupt from bmc150accelbufferpostenable+0x40/0x108 bmc150accelbuffer_postenable from __iioupdatebuffers+0xbe0/0xcbc _iioupdatebuffers from enablestore+0x84/0xc8 enablestore from kernfsfopwriteiter+0x154/0x1b4

This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why.

Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.(CVE-2025-68330)

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

iio: adc: at91-sama5d2adc: Fix potential use-after-free in sama5d2adc driver

at91adcinterrupt can call at91adctouchdatahandler function to start the work by schedulework(&st->touchst.workq).

If we remove the module which will call at91adcremove to make cleanup, it will free indiodev through iiodevice_unregister but quite a bit later. While the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:

CPU0 CPU1

                                 | at91_adc_workq_handler

at91adcremove | iiodeviceunregister(indiodev) | //free indiodev a bit later | | iiopushtobuffers(indiodev) | //use indio_dev

Fix it by ensuring that the work is canceled before proceeding with the cleanup in at91adcremove.(CVE-2025-71199)

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

nilfs2: Fix potential block overflow that cause system hang

When a user executes the FITRIM command, an underflow can occur when calculating nblocks if endblock is too small. Since nblocks is of type sectort, which is u64, a negative nblocks value will become a very large positive integer. This ultimately leads to the block layer function __blkdevissuediscard() taking an excessively long time to process the bio chain, and the nssegctorsem lock remains held for a long period. This prevents other tasks from acquiring the nssegctorsem lock, resulting in the hang reported by syzbot in [1].

If the ending block is too small, typically if it is smaller than 4KiB range, depending on the usage of the segment 0, it may be possible to attempt a discard request beyond the device size causing the hang.

Exiting successfully and assign the discarded size (0 in this case) to range->len.

Although the start and len values in the user input range are too small, a conservative strategy is adopted here to safely ignore them, which is equivalent to a no-op; it will not perform any trimming and will not throw an error.

[1] task:segctord state:D stack:28968 pid:6093 tgid:6093 ppid:2 taskflags:0x200040 flags:0x00080000 Call Trace: rwbasewritelock+0x3dd/0x750 kernel/locking/rwbasert.c:272 nilfstransactionlock+0x253/0x4c0 fs/nilfs2/segment.c:357 nilfssegctorthreadconstruct fs/nilfs2/segment.c:2569 [inline] nilfssegctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684

ryusuke: corrected part of the commit message about the consequences

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

dmaengine: omap-dma: fix dma_pool resource leak in error paths

The dmapool created by dmapoolcreate() is not destroyed when dmaasyncdeviceregister() or ofdmacontroller_register() fails, causing a resource leak in the probe error paths.

Add dmapooldestroy() in both error paths to properly release the allocated dma_pool resource.(CVE-2026-23033)

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

net/sched: act_ife: avoid possible NULL deref

tcfifeencode() must make sure ife_encode() does not return NULL.

syzbot reported:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ifetlvmetaencode+0x41/0xa0 net/ife/ife.c:166 CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full) Call Trace: <TASK> ifeencodemetau32+0x153/0x180 net/sched/actife.c:101 tcfifeencode net/sched/actife.c:841 [inline] tcfifeact+0x1022/0x1de0 net/sched/actife.c:877 tcact include/net/tcwrapper.h:130 [inline] tcfactionexec+0x1c0/0xa20 net/sched/actapi.c:1152 tcfextsexec include/net/pktcls.h:349 [inline] mallclassify+0x1a0/0x2a0 net/sched/clsmatchall.c:42 tcclassify include/net/tc_wrapper.h:197 [inline] __tcfclassify net/sched/clsapi.c:1764 [inline] tcfclassify+0x7f2/0x1380 net/sched/clsapi.c:1860 multiqclassify net/sched/schmultiq.c:39 [inline] multiqenqueue+0xe0/0x510 net/sched/schmultiq.c:66 devqdiscenqueue+0x45/0x250 net/core/dev.c:4147 __devxmitskb net/core/dev.c:4262 [inline] __devqueuexmit+0x2998/0x46c0 net/core/dev.c:4798(CVE-2026-23064)

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

wifi: rsi: Fix memory corruption due to not set vif driver data size

The struct ieee80211vif contains trailing space for vif driver data, when struct ieee80211vif is allocated, the total memory size that is allocated is sizeof(struct ieee80211_vif) + size of vif driver data. The size of vif driver data is set by each WiFi driver as needed.

The RSI911x driver does not set vif driver data size, no trailing space for vif driver data is therefore allocated past struct ieee80211vif . The RSI911x driver does however use the vif driver data to store its vif driver data structure "struct vifpriv". An access to vif->drvpriv leads to access out of struct ieee80211vif bounds and corruption of some memory.

In case of the failure observed locally, rsimac80211addinterface() would write struct vifpriv *vifinfo = (struct vifpriv *)vif->drvpriv; vifinfo->vapid = vapidx. This write corrupts struct fqtin member struct listhead newflows . The flow = listfirstentry(head, struct fqflow, flowchain); in fqtinreset() then reports non-NULL bogus address, which when accessed causes a crash.

The trigger is very simple, boot the machine with init=/bin/sh , mount devtmpfs, sysfs, procfs, and then do "ip link set wlan0 up", "sleep 1", "ip link set wlan0 down" and the crash occurs.

Fix this by setting the correct size of vif driver data, which is the size of "struct vif_priv", so that memory is allocated and the driver can store its driver data in it, instead of corrupting memory around it.(CVE-2026-23073)

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

netrom: fix double-free in nrrouteframe()

In nrrouteframe(), oldskb is immediately freed without checking if nrneigh->ax25 pointer is NULL. Therefore, if nrneigh->ax25 is NULL, the caller function will free oldskb again, causing a double-free bug.

Therefore, to prevent this, we need to modify it to check whether nrneigh->ax25 is NULL before freeing oldskb.(CVE-2026-23098)

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

platform/x86: toshiba_haps: Fix memory leaks in add/remove routines

toshibahapsadd() leaks the haps object allocated by it if it returns an error after allocating that object successfully.

toshibahapsremove() does not free the object pointed to by toshiba_haps before clearing that pointer, so it becomes unreachable allocated memory.

Address these memory leaks by using devm_kzalloc() for allocating the memory in question.(CVE-2026-23176)

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

scsi: ibmvfc: Fix OOB access in ibmvfcdiscovertargets_done()

A malicious or compromised VIO server can return a numwritten value in the discover targets MAD response that exceeds maxtargets. This value is stored directly in vhost->numtargets without validation, and is then used as the loop bound in ibmvfcalloctargets() to index into discbuf[], which is only allocated for maxtargets entries. Indices at or beyond maxtargets access kernel memory outside the DMA-coherent allocation. The out-of-bounds data is subsequently embedded in Implicit Logout and PLOGI MADs that are sent back to the VIO server, leaking kernel memory.

Fix by clamping numwritten to maxtargets before storing it.(CVE-2026-31464)

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

ocfs2: fix use-after-free in ocfs2fault() when VMFAULT_RETRY

filemapfault() may drop the mmaplock before returning VMFAULTRETRY, as documented in mm/filemap.c:

"If our return value has VMFAULTRETRY set, it's because the mmaplock may be dropped before doing I/O or by lockfoliomaybedrop_mmap()."

When this happens, a concurrent munmap() can call removevma() and free the vmareastruct via RCU. The saved 'vma' pointer in ocfs2fault() then becomes a dangling pointer, and the subsequent traceocfs2fault() call dereferences it -- a use-after-free.

Fix this by saving ipblkno as a plain integer before calling filemapfault(), and removing vma from the trace event. Since ip_blkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward.(CVE-2026-31597)

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

ocfs2: fix possible deadlock between unlink and dioendio_write

ocfs2unlink takes orphan dir inodelock first and then ipallocsem, while in ocfs2dioendiowrite, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2sysfilelockkey[ORPHANDIRSYSTEMINODE] and ocfs2fileipallocsem_key.

Lock Chain #0 (orphan dir inodelock -> ipallocsem): ocfs2unlink ocfs2prepareorphandir ocfs2lookuplockorphandir inodelock(orphandirinode) <- lock A _ocfs2prepareorphandir ocfs2preparedirforinsert ocfs2extenddir ocfs2expandinlinedir downwrite(&oi->ipallocsem) <- Lock B

Lock Chain #1 (ipallocsem -> orphan dir inodelock): ocfs2dioendiowrite downwrite(&oi->ipallocsem) <- Lock B ocfs2delinodefromorphan() inodelock(orphandir_inode) <- Lock A

Deadlock Scenario: CPU0 (unlink) CPU1 (dioendiowrite) ------ ------ inodelock(orphandirinode) downwrite(ipallocsem) downwrite(ipallocsem) inodelock(orphandir_inode)

Since ipallocsem is to protect allocation changes, which is unrelated with operations in ocfs2delinodefromorphan. So move ocfs2delinodefromorphan out of ipallocsem to fix the deadlock.(CVE-2026-31598)

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

usbip: validate numberofpackets in usbippackret_submit()

When a USB/IP client receives a RETSUBMIT response, usbippackretsubmit() unconditionally overwrites urb->numberofpackets from the network PDU. This value is subsequently used as the loop bound in usbiprecviso() and usbippadiso() to iterate over urb->isoframedesc[], a flexible array whose size was fixed at URB allocation time based on the original numberofpackets from the CMD_SUBMIT.

A malicious USB/IP server can set numberofpackets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbiprecviso() writes to urb->isoframedesc[i] beyond the allocated region.

KASAN confirmed this with kernel 7.0.0-rc5:

BUG: KASAN: slab-out-of-bounds in usbiprecviso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69

The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40)

The server side (stubrx.c) and gadget side (vudcrx.c) already validate numberofpackets in the CMDSUBMIT path since commits c6688ef9f297 ("usbip: fix stubrx: harden CMDSUBMIT path to handle malicious input") and b78d830f0049 ("usbip: fix vudcrx: harden CMDSUBMIT path to handle malicious input"). The server side validates against USBIPMAXISOPACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original numberofpackets.

This mirrors the existing validation of actuallength against transferbufferlength in usbiprecv_xbuff(), which checks the response value against the original allocation size.

Kelvin Mbogo's series ("usb: usbip: fix integer overflow in usbiprecviso()", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbippackretsubmit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIPMAXISOPACKETS limit.

Fix this by checking rpdu->numberofpackets against urb->numberofpackets in usbippackretsubmit() before the overwrite. On violation, clamp to zero so that usbiprecviso() and usbippad_iso() safely return early.(CVE-2026-31607)

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

fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO

Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide by zero error"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.(CVE-2026-31618)

In the Linux kernel, the following vulnerability has been resolved: NFC: digital: Bounds check NFC-A cascade depth in SDD response handler. The NFC-A anti-collision cascade in digitalinrecvsddres() appends 3 or 4 bytes to target->nfcid1 on each round, but the number of cascade rounds is controlled entirely by the peer device. The peer sets the cascade tag in the SDDRES (deciding 3 vs 4 bytes) and the cascade-incomplete bit in the SELRES (deciding whether another round follows). ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is sized accordingly (NFCNFCID1MAXSIZE = 10), but nothing in the driver actually enforces this. This means a malicious peer can keep the cascade running, writing past the heap-allocated nfctarget with each round. Fix this by rejecting the response when the accumulated UID would exceed the buffer. Commit e329e71013c9 ("NFC: nci: Bounds check struct nfctarget arrays") fixed similar missing checks against the same field on the NCI path.(CVE-2026-31622)

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

fbdev: vt8500lcdfb: fix missing dmafreecoherent()

fbi->fb.screenbuffer is allocated with dmaalloc_coherent() but is not freed if the error path is reached.(CVE-2026-43202)

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

net/rds: No shortcut out of RDSCONNERROR

RDS connections carry a state "rdsconnpath::cpstate" and transitions from one state to another and are conditional upon an expected state: "rdsconnpathtransition."

There is one exception to this conditionality, which is "RDSCONNERROR" that can be enforced by "rdsconnpath_drop" regardless of what state the condition is currently in.

But as soon as a connection enters state "RDSCONNERROR", the connection handling code expects it to go through the shutdown-path.

The RDS/TCP multipath changes added a shortcut out of "RDSCONNERROR" straight back to "RDSCONNCONNECTING" via "rdstcpacceptonepath" (e.g. after "rdstcpstate_change").

A subsequent "rdstcpresetcallbacks" can then transition the state to "RDSCONN_RESETTING" with a shutdown-worker queued.

That'll trip up "rdsconninitshutdown", which was never adjusted to handle "RDSCONNRESETTING" and subsequently drops the connection with the dreaded "DRINVCONNSTATE", which leaves "RDSSHUTDOWNWORK_QUEUED" on forever.

So we do two things here:

a) Don't shortcut "RDSCONNERROR", but take the longer path through the shutdown code.

b) Add "RDSCONNRESETTING" to the expected states in "rdsconninit_shutdown" so that we won't error out and get stuck, if we ever hit weird state transitions like this again."(CVE-2026-43226)

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

misc: ibmasm: fix OOB MMIO read in ibmasmhandlemouse_interrupt()

ibmasmhandlemouseinterrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTEQUEUE_SIZE (60).

A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started.

The root cause is that getqueuereader() and getqueuewriter() return raw readl() values that are passed directly into getqueueentry(), which computes:

queuebegin + reader * sizeof(struct remoteinput)

with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception.

Fix by checking both indices against REMOTEQUEUESIZE at the top of the loop body, before any call to getqueueentry(). On an out-of-range value, reset the reader register to 0 via setqueuereader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient.(CVE-2026-46022)

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

net: caif: clear client service pointer on teardown

caif_connect() can tear down an existing client after remote shutdown by calling caif_disconnect_client() followed by caif_free_client(). caif_free_client() releases the service layer referenced by adap_layer->dn, but leaves that pointer stale.

When the socket is later destroyed, caif_sock_destructor() calls caif_free_client() again and dereferences the freed service pointer.

Clear the client/service links before releasing the service object so repeated teardown becomes harmless.(CVE-2026-46098)