OESA-2026-3702

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net/9p: fix double req put in p9fdcancelled

Syzkaller reports a KASAN issue as below:

general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f] CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:__list_del include/linux/list.h:114 [inline] RIP: 0010:__listdelentry include/linux/list.h:137 [inline] RIP: 0010:listdel include/linux/list.h:148 [inline] RIP: 0010:p9fdcancelled+0xe9/0x200 net/9p/transfd.c:734

Call Trace: <TASK> p9clientflush+0x351/0x440 net/9p/client.c:614 p9clientrpc+0xb6b/0xc70 net/9p/client.c:734 p9clientversion net/9p/client.c:920 [inline] p9clientcreate+0xb51/0x1240 net/9p/client.c:1027 v9fssessioninit+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fsmount+0xba/0xcb0 fs/9p/vfssuper.c:126 legacygettree+0x108/0x220 fs/fscontext.c:632 vfsgettree+0x8e/0x300 fs/super.c:1573 donewmount fs/namespace.c:3056 [inline] pathmount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __dosysmount fs/namespace.c:3607 [inline] __sesysmount fs/namespace.c:3584 [inline] __x64sysmount+0x283/0x300 fs/namespace.c:3584 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x35/0x80 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x6e/0xd8

This happens because of a race condition between:

• The 9p client sending an invalid flush request and later cleaning it up;

• The 9p client in p9readwork() canceled all pending requests.

  Thread 1                              Thread 2
  

  ... p9clientcreate() ... p9fdcreate() ... p9conncreate() ... // start Thread 2 INITWORK(&m->rq, p9readwork); p9readwork() ... p9clientrpc() ... ... p9conncancel() ... spinlock(&m->reqlock); ... p9fdcancelled() ... ... spinunlock(&m->reqlock); // status rewrite p9clientcb(m->client, req, REQSTATUSERROR) // first remove listdel(&req->req_list); ...

  spinlock(&m->reqlock) ... // second remove listdel(&req->reqlist); spinunlock(&m->reqlock) ...

Commit 74d6a5d56629 ("9p/transfd: Fix concurrency del of reqlist in p9fdcancelled/p9readwork") fixes a concurrency issue in the 9p filesystem client where the reqlist could be deleted simultaneously by both p9readwork and p9fdcancelled functions, but for the case where req->status equals REQSTATUS_RCVD.

Update the check for req->status in p9fdcancelled to skip processing not just received requests, but anything that is not SENT, as whatever changed the state from SENT also removed the request from its list.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

updated the check from status == RECV || status == ERROR to status != SENT

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

exfat: validate cluster allocation bits of the allocation bitmap

syzbot created an exfat image with cluster bits not set for the allocation bitmap. exfat-fs reads and uses the allocation bitmap without checking this. The problem is that if the start cluster of the allocation bitmap is 6, cluster 6 can be allocated when creating a directory with mkdir. exfat zeros out this cluster in exfatmkdir, which can delete existing entries. This can reallocate the allocated entries. In addition, the allocation bitmap is also zeroed out, so cluster 6 can be reallocated. This patch adds exfattestbitmaprange to validate that clusters used for the allocation bitmap are correctly marked as in-use.(CVE-2025-40307)

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

batman-adv: stop tp_meter sessions during mesh teardown

TP meter sessions remain linked on batpriv->tplist after the netlink request has already finished. When the mesh interface is removed, batadvmeshfree() currently tears down the mesh without first draining these sessions.

A running sender thread or a late incoming tpmeter packet can then keep processing against a mesh instance which is already shutting down. Synchronize tpmeter with the mesh lifetime by stopping all active sessions from batadvmeshfree() and waiting for sender threads to exit before teardown continues.(CVE-2026-46208)

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

sctp: diag: reject stale associations in dump_one path

The SCTP exact sockdiag lookup can hold a transport reference, block on locksock(sk), and then resume after sctpassociationfree() has marked the association dead and freed its bind address list.

When that happens, inetassocattrsize() and inetdiagmsgsctpasocfill() can still dereference association state that is no longer valid for reporting. In particular, inetdiagmsgsctpasocfill() may read an empty bind-address list as a real sctpsockaddr_entry and trigger an out-of-bounds read from unrelated association memory.

Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.(CVE-2026-52917)

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

libceph: Fix potential out-of-bounds access in crush_decode()

A message of type CEPHMSGOSD_MAP containing a crush map with at least one bucket has two fields holding the bucket algorithm. If the values in these two fields differ, an out-of-bounds access can occur. This is the case because the first algorithm field (alg) is used to allocate the correct amount of memory for a bucket of this type, while the second algorithm field inside the bucket (b->alg) is used in the subsequent processing.

This patch fixes the issue by adding a check that compares alg and b->alg and aborts the processing in case they differ. Furthermore, b->alg is set to 0 in this case, because the destruction of the crush map also uses this field to determine the bucket type, which can again result in an out-of-bounds access when trying to free the memory pointed to by the fields of the bucket. To correctly free the memory allocated for the bucket in such a case, the corresponding call to kfree is moved from the algorithm-specific crushdestroybucket functions to the generic crushdestroybucket().(CVE-2026-52955)

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

hvnetvsc: use kmaplocalpage in netvsccopytosend_buf

netvsccopytosendbuf() copies page buffer entries into the VMBus send buffer using phystovirt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIGHIGHMEM=y can live above the LOWMEM boundary. For such a page physto_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal.

Map the pages with kmaplocalpage() instead, handling two properties of the page buffer entries:

• pb[i].pfn is a Hyper-V PFN at HVHYPPAGESIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGESIZE > HVHYPPAGE_SIZE (e.g. arm64 with 64K pages).

• Since commit 41a6328b2c55 ("hvnetvsc: Preserve contiguous PFN grouping in the page buffer array"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGESIZE, while kmaplocalpage() maps a single page. Copy page by page, splitting at native page boundaries.

The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cppartial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIGHIGHMEM configs kmaplocalpage() folds to page_address() and no mapping work is added.(CVE-2026-53199)

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

sctp: fix uninit-value in _sctprcvasconflookup()

_sctprcvasconflookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->fromaddrparam(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length.

An unauthenticated peer can send a truncated trailing ASCONF chunk that declares an IPv6 address parameter but stops after the 4-byte parameter header; reached from the no-association lookup path, fromaddrparam() then reads uninitialized bytes past the parameter.

Impact: an unauthenticated SCTP peer makes the receive path read up to 16 bytes of uninitialized memory past a truncated ASCONF address parameter.

The sibling _sctprcvinitlookup() bounds parameters with sctpwalkparams(); this path open-codes the fetch and omits the bound. Verify the whole address parameter lies within the chunk before fromaddrparam() reads it, the same class of fix as commit 51e5ad549c43 ("net: sctp: fix KMSAN uninit-value in sctpinqpop").(CVE-2026-53225)

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

tipc: fix slab-use-after-free Read in tipcaeaddecrypt_done

tipcaeaddecrypt() goes straight from tipcbearerhold(b) to cryptoaeaddecrypt(req) without taking a reference on the netns, unlike the encrypt path. When cryptoaeaddecrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipcaeaddecryptdone() later. If the bearer's netns is torn down in the meantime, cleanupnet() -> tipcexitnet() -> tipccryptostop() frees the per-netns tipccrypto, and the completion then reads it: tipcaeaddecryptdone() dereferences aead->crypto->stats and aead->crypto->net, and tipccryptorcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory.

Decoded KASAN splat (v7.1-rc7, CONFIGKASANINLINE + TIPC + TIPC_CRYPTO):

BUG: KASAN: slab-use-after-free in tipcaeaddecryptdone (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: eventsunbound Call Trace: tipcaeaddecryptdone (net/tipc/crypto.c:999) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245)

Allocated by task 169: __kasankmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipccryptostart (net/tipc/crypto.c:1502) tipcinitnet (net/tipc/core.c:72) opsinit (net/core/netnamespace.c:137) setupnet (net/core/netnamespace.c:446) copynetns (net/core/netnamespace.c:579) createnewnamespaces (kernel/nsproxy.c:132) __x64sysunshare (kernel/fork.c:3316) dosyscall64 (arch/x86/entry/syscall64.c:63) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121)

Freed by task 8: kfree (mm/slub.c:6566) tipcexitnet (net/tipc/core.c:119) cleanupnet (net/core/netnamespace.c:704) processonework (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436)

This is the same class of bug that commit e279024617134 ("net/tipc: fix slab-use-after-free Read in tipcaeadencryptdone") fixed for the encrypt side. The encrypt path takes maybegetnet(aead->crypto->net) before cryptoaeadencrypt() and drops it with putnet() on the synchronous return paths and in tipcaeadencrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard.

Mirror the encrypt-side fix on the decrypt path: take a net reference before cryptoaeaddecrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with putnet() on the synchronous success/error return and at the end of tipcaeaddecryptdone().

Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipccryptostop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipcaeaddecryptdone() is the unpatched upstream path; tipcaeaddecrypt() still lacks maybegetnet(aead->crypto->net), so the completion can outlive the free on any config where cryptoaead_decrypt() goes async.

Found by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-63801)

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

netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without direction check

An unintended behavior in the TCP conntrack state machine allows a connection to be forced into the CLOSE state using an RST packet with an invalid sequence number.

Specifically, after a SYN packet is observed, an RST with an invalid SEQ can transition the conntrack entry to TCPCONNTRACKCLOSE, regardless of whether the RST corresponds to the expected reply direction. The relevant code path assumes the RST is a response to an outgoing SYN, but does not validate packet direction or ensure that a matching SYN was actually sent in the opposite direction.

As a result, a crafted packet sequence consisting of a SYN followed by an invalid-sequence RST can prematurely terminate an active NAT entry. This makes connection teardown easier than intended.

So, tighten the state transition logic to ensure that RST-triggered CLOSE transitions only occur when the RST is a valid response to a previously observed SYN in the correct direction.(CVE-2026-63913)

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

xfrm: route MIGRATE notifications to caller's netns

xfrmsendmigrate() in net/xfrm/xfrmuser.c and pfkeysendmigrate() in net/key/afkey.c both hardcode &initnet for the multicast that announces a successful XFRMMSGMIGRATE / SADBX_MIGRATE.

XFRMMSGMIGRATE arrives on a per-netns NETLINKXFRM socket, and the rest of the xfrm/afkey netlink path was made netns-aware in 2008. The other 14 multicast paths in xfrmuser.c route their event using xsnet(x), xpnet(xp) or socknet(skb->sk); only the migrate path was missed.

Two consequences of the init_net hardcoding:

1. The notification (selector, old/new endpoint addresses, and the kmaddress) is delivered to listeners on initnet's XFRMNLGRPMIGRATE / pfkey BROADCASTALL groups rather than on the issuing netns. An IKE daemon running in init_net therefore receives migration notifications originating from any other netns on the host.

2. An IKE daemon running inside a non-init netns and subscribed to its own XFRMNLGRP_MIGRATE / pfkey groups never receives the notification of its own migration. IKEv2 MOBIKE / address-update handling inside a netns is silently broken.

Thread struct net through kmmigrate() and the xfrmmgr.migrate function pointer, drop the &initnet override in xfrmsendmigrate() and pfkeysendmigrate(), and pass the caller's net (already in scope in xfrmmigrate() via socknet(skb->sk)) all the way down. struct xfrmmgr is in-tree only and not exported as a stable API, so the function-pointer signature change is internal.

pfkeybroadcast() is already netns-aware via netgeneric(net, pfkeynetid) since the pernet conversion. The five other pfkeybroadcast() callers in afkey.c already pass xsnet(x), socknet(sk) or a per-netns net, so this only removes the &init_net outlier.(CVE-2026-63914)

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

sctp: fix race between sctpwaitfor_connect and peeloff

sctpwaitforconnect() drops and re-acquires the socket lock while waiting for the association to reach ESTABLISHED state. During this window, another thread can peeloff the association to a new socket via getsockopt(SCTPSOCKOPTPEELOFF), changing asoc->base.sk. After re-acquiring the old socket lock, sctpwaitforconnect() returns success without noticing the migration — the caller then accesses the association under the wrong lock in sctpdatamsgfrom_user().

Add the same sk != asoc->base.sk check that sctpwaitfor_sndbuf() already has, returning an error if the association was migrated while we slept.(CVE-2026-63971)

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

batman-adv: tt: fix negative lastchangesetlen

batadvpivtt::lastchangesetlen len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer.

In batadvsendmyttresponse(), lastchangesetlen is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadvttpreparetvlvlocal_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized.

Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadvsendmyttresponse().(CVE-2026-64089)

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

batman-adv: bla: avoid double decrement of bla.num_requests

The bla.numrequests is increased when no requestsent was in progress. And it is decremented in various places (announcement was received, backbone is purged, periodic work). But the check if the requestsent is actually set to a specific state and the atomicdec/_inc are not safe because they are not atomic (TOCTOU) and multiple such code portions can run concurrently.

At the same time, it is necessary to modify requestsent (state) and bla.numrequests atomically. Otherwise batadvblasendrequest() might set requestsent to 1 and is interrupted. batadvhandleannounce() can then set requestsent back to 0 and decrement numrequests before batadvblasend_request() incremented it.

The two operations must therefore be locked. And since state (requestsent) and waitperiods are only accessed inside this lock, they can be converted to simpler datatypes. And to avoid that the bla.numrequests is touched by a parallel running context with a valid backbonegw reference after batadvblapurgebackbonegw() ran, a third state "stopped" is required to correctly signal that a backbone_gw is in the state of being cleaned up.(CVE-2026-64095)

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

net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()

rmnetdellink() removes the endpoint from the hash table with hlistdelinitrcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnetrxhandler -> _rmnetmapingresshandler) may still hold a reference to the endpoint and dereference ep->egressdev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egressdev pointer.

BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: pocwrite Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnetvndrxfixup (rmnet_vnd.c:27) Call Trace: <TASK> __rmnetmapingresshandler (rmnethandlers.c:48 rmnethandlers.c:101) rmnetrxhandler (rmnethandlers.c:129 rmnet_handlers.c:235) __netifreceiveskb_core.constprop.0 (net/core/dev.c:6096) _netifreceiveskbonecore (net/core/dev.c:6208) netifreceiveskb (net/core/dev.c:6467) tungetuser (drivers/net/tun.c:1955) tunchrwriteiter (drivers/net/tun.c:2003) vfswrite (fs/readwrite.c:688) ksyswrite (fs/readwrite.c:740) </TASK>

Add an rcuhead field to struct rmnetendpoint and replace kfree() with kfreercu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnetvnddellink() call and inline only the nrrmnetdevs decrement, since rmnetvnddellink() would set ep->egressdev to NULL during the grace period, creating a data race with lockless readers.(CVE-2026-64188)

In the Linux kernel, the following vulnerability has been resolved: tipc: fix out-of-bounds read in broadcast Gap ACK blocks. A broadcast PROTOCOL/STATEMSG can carry a Gap ACK blocks record in its data area. tipcgetgapackblks() only verifies that the record's len field is self-consistent with its ugackcnt/bgackcnt counts (sz == structsize(p, gacks, ugackcnt + bgackcnt)); it does not check that the record actually fits in the message data area, msgdatasz(). The unicast caller tipclinkprotorcv() bounds it, but the broadcast caller tipcbcastsyncrcv() discards the returned size, so tipclinkadvance_transmq() copies the record off the receive skb with an attacker-controlled count, leading to an out-of-bounds read. This could allow an attacker to read beyond the allocated buffer, potentially causing information disclosure or system crash.(CVE-2026-64450)

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

Bluetooth: btusb: fix use-after-free on registration failure

Make sure to release the sibling interfaces in case controller registration fails to avoid use-after-free and double-free when they are eventually disconnected.

This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.(CVE-2026-64471)

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

ALSA: firewire: isight: bound the sample count to the packet payload

isight_packet() takes the frame count from the device iso packet and checks it only against the device claimed iso length.

count = be32_to_cpu(payload->sample_count);
if (likely(count <= (length - 16) / 4))
    isight_samples(isight, payload->samples, count);

length is the iso header datalength. It can be up to 0xffff. So the gate allows a count up to about 16379. isightsamples() then copies count frames out of payload->samples into the PCM DMA buffer.

payload->samples holds only 2 * MAXFRAMESPERPACKET values. The device multiplexes two samples per frame. A count past MAXFRAMESPERPACKET reads past the payload. A count past the buffer size writes past runtime->dmaarea. The smallest PCM buffer is larger than MAXFRAMESPERPACKET. Bounding the count to MAXFRAMESPER_PACKET keeps both the read and the write in range.

A malicious or faulty Apple iSight on the FireWire bus reaches this during a normal capture.

Add the MAXFRAMESPER_PACKET bound to the gate.(CVE-2026-64483)

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

libceph: Reject monmaps advertising zero monitors

A message of type CEPHMSGMON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in _opensession(). This happens because the "BUGON(monc->monmap->nummon < 1)" assertion in picknewmon() is triggered.

This patch extends a check in cephmonmapdecode() to also reject arriving monmaps with nummon == 0 rather than only with nummon > CEPHMAX_MON.

idryomov: drop "log output for unusual values of num_mon" part

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

libceph: refresh auth->authorizer_buf{,_len} after authorizer update

cephxcreateauthorizer() caches au->buf->vec.iovbase and au->buf->vec.iovlen in struct cephauth_handshake. These cached values are then used by the messenger connect code when sending the authorizer.

cephxupdateauthorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, cephxbuildauthorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, cephbufferput() frees the old cephbuffer and its vec.iovbase, but auth->authorizer_buf still points at that freed memory.

A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in copyfromiter() while tcpsendmsg() copies the authorizer.

Refresh auth->authorizerbuf and auth->authorizerbuf_len after a successful authorizer rebuild so the messenger sends the current buffer.(CVE-2026-68156)

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

media: cx231xx: fix devres lifetime

USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes).

Fix the driver state lifetime so that it is released on driver unbind.(CVE-2026-68227)

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

IB/mad: Drop unmatched RMPP responses before reassembly

Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ibprocessrmpprecvwc() has either assembled a complete message or consumed the segment.

That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send.

For kernel-handled RMPP DATA responses, require the existing ibfindsend_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state.

This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.(CVE-2026-68425)

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

ntfs: sanitize MFT references returned from ntfslookupinodebyname()

ntfslookupinodebyname() returns MFT references read from directory index entries on disk. These values are untrusted, but the function can currently return an error-marked MFT reference to its callers without validating it.

Callers later decode lookup failures with MREF_ERR(). A crafted NTFS image can set the MREF error bit while leaving the low bits as an arbitrary value, causing callers to consume a bogus pseudo-errno instead of treating the lookup result as corrupted on-disk metadata.

Fix this at the source by normalizing every error-marked MFT reference returned from ntfslookupinodebyname() to ERR_MREF(-EIO). Apply this to all four directory lookup return paths so every caller gets a validated result without needing additional checks or an API change.

This keeps the sanitization in the common lookup helper, which is cleaner than duplicating validation in each caller.(CVE-2026-72188)

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

RDMA/mlx5: Fix undefined shift of user RQ WQE size

setrqsize() computes the RQ WQE size as "1 << rqwqeshift" based on the user-provided rqwqeshift, which is only checked to be greater than 32, so shifts of 32 are still accepted. A shift of 31 also overflows a signed integer, leading to undefined behavior.

Use checkshloverflow() to compute the RQ WQE size and reject any invalid values.(CVE-2026-74297)

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

Bluetooth: hcicore: Fix UAF in hciunregister_dev()

hciunregisterdev() does not disable cmdtimer and ncmdtimer before the hci_dev structure is freed. If a timeout fires during device teardown, the callback dereferences freed memory (including the hdev->reset function pointer), leading to a use-after-free.

Add disabledelayedworksync() calls alongside the existing disablework_sync() calls to ensure both timers are fully quiesced before teardown proceeds.(CVE-2026-74302)

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

RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path

For non-SRQ QPs, the responder reads WQE fields directly from the shared queue buffer mapped into userspace. This allows a malicious user to modify fields like numsge or sge entries while the kernel is processing the WQE, leading to out-of-bounds reads in rxerespchecklength() and copy_data().

Introduce getrecvwqe() that validates numsge and copies the WQE to a kernel-local buffer before processing, matching the approach already used for SRQ WQEs in getsrqwqe(). The srqwqe buffer is reused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)

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

RDMA/srpt: fix integer overflow in immediate data length check

immbuf->len is a user-controlled uint32t received from the network. Adding it to immdataoffset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing reqsize to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sginit_one().

Use checkaddoverflow() to detect wrapping before the comparison.(CVE-2026-74394)

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

RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference

MLX5IBMETHODDEVXSUBSCRIBEEVENT() links eventsub into sub_list before initializing the fields used by the shared error path.

If eventfdctxfdget() then fails, the unwind path dereferences eventsub->evfile in uverbsuobjectput() and calls subscribeeventxadealloc() with an unset xakey_level1.

subscribeeventxaalloc() creates the XA entry exactly once for a given keylevel1, on the first occurrence of that key. The unwind path must therefore call subscribeeventxa_dealloc() exactly once for it as well.

Enforce that by adding devxkeyinsublist() and calling subscribeeventxa_dealloc() only when the last matching pending entry is being cleaned up.(CVE-2026-74395)

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

IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier

mlx5iballoctransportdomain() allocates a transport domain and then may fail in mlx5ibenable_lb(). In that case, the allocated TD is leaked.

Fix this by deallocating the TD when mlx5ibenablelb() returns an error. Also return 0 explicitly in the no-loopback-capability success branch, and move dev->lb.mutex initialization to mlx5ibstageinit_init().(CVE-2026-74397)

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

ALSA: usb-audio: fix OOB write in sndusbmidiakai_output()

sndusbmidiakai_output() computes its fill-loop bound

buf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1;

as a signed int, so a small device-advertised bulk-OUT maxtransfer makes bufend negative. The loop guard then compares the u32 urb->transferbufferlength against that negative int: the usual arithmetic conversion turns bufend into a large unsigned value, so the guard stays true and each iteration keeps appending SysEx framing and payload bytes past the end of the URB transfer buffer, which is only maxtransfer bytes long.

A USB device that advertises a tiny bulk-OUT endpoint can therefore trigger an attacker-length- and content-controlled heap out-of-bounds write when a process writes to the created /dev/snd/midiCD node.

Return early when there is no room for even one SysEx, so the loop is never entered with a bound that would wrap. The loop is the last statement of the function, so bailing out is equivalent to it not running.

Discovered by XBOW, triaged by Baul Lee <(CVE-2026-74499)

In the Linux kernel, the following vulnerability has been resolved: sctp: keep chunk->transport in step with the list it is queued on. _sctpoutqflushrtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport. The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctpassocrmpeer() from an ASCONF Delete-IP - sctptransportfree() RCU-frees it and the chunk is left with a dangling pointer. A SACK that reneges on the TSN clears the flag, and the next SACK reaches inside the freed transport. KASAN reports a slab-use-after-free read in sctpchecktransmitted(), freed from sctpassocrmpeer().(CVE-2026-74588)

In the Linux kernel, a deadlock vulnerability has been found in the ceph filesystem. A reader can hang forever in _cephgetcaps() when the client no longer holds FILERD, but local cap state still says that the capability is already wanted (via mdswanted). One way to trigger this is through MDS cap revocation. If another client performs a conflicting operation, the MDS can revoke FILERD from the reader; the next read then has to reacquire FILERD. If the cap update that should request FILERD never reaches the MDS after cap->mdswanted was raised, the reader is left holding only non-file caps while local mdswanted still includes the file read caps, causing the reader to wait indefinitely.(CVE-2026-80527)

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

libceph: fix OOB read in decode_watchers() via missing bounds check

cephstartdecoding() validates that structlen bytes remain in the buffer after the encoding header, but accepts structlen=0 as valid: cephdecodeneed(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an objlistwatchresponset reply with structlen=0, cephstart_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads.

The immediately following cephdecode32(p) in decodewatchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzallocobjs() as the watcher count.

The sibling function decodewatcher() already uses the safe variants (cephdecodecopysafe, cephdecode64safe, cephdecodeskip32) after its own cephstartdecoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight.

Fix by replacing cephdecode32(p) with cephdecode32safe(p, end, *numwatchers, bad), consistent with the established pattern.

Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPHOSDOPLISTWATCHERS, without any further privileges beyond OSD session establishment.

idryomov: trim changelog