OESA-2026-2416

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

smb: client: fix use-after-free in crypt_message when using async crypto

The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:

cryptmessage() // Allocate the creq buffer containing the req creq = smb2getaeadreq(..., &req);

// Async encryption returns -EINPROGRESS immediately
rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);

// Free creq while async operation is still in progress
kvfree_sensitive(creq, ...);

Hardware crypto modules often implement async AEAD operations for performance. When cryptoaeadencrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without cryptowaitreq(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.

This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.

The issue occurs because cryptoallocaead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTOALGASYNC in the mask, async implementations can be selected.

Fix by restoring the async crypto handling: - DECLARECRYPTOWAIT(wait) for completion tracking - aeadrequestsetcallback() for async completion notification - cryptowait_req() to wait for operation completion

This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix.(CVE-2025-38488)

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

scsi: lpfc: Fix buffer free/clear order in deferred receive path

Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF.

Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same.(CVE-2025-39841)

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

nvme: nvme-fc: Ensure ->ioerrwork is cancelled in nvmefcdeletectrl()

nvmefcdeleteassocation() waits for pending I/O to complete before returning, and an error can cause ->ioerrwork to be queued after cancelworksync() had been called. Move the call to cancelworksync() to be after nvmefcdeleteassociation() to ensure ->ioerrwork is not running when the nvmefcctrl object is freed. Otherwise the following can occur:

[ 1135.911754] listdel corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/listdebug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__listdelentry_validorreport.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] <TASK> [ 1136.063179] ? showtraceloglvl+0x1b0/0x2f0 [ 1136.067540] ? showtraceloglvl+0x1b0/0x2f0 [ 1136.071898] ? movelinkedworks+0x4a/0xa0 [ 1136.075998] ? __listdelentry_validorreport.cold+0xf/0x6f [ 1136.081744] ? __diebody.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? dotrap+0xca/0x110 [ 1136.091789] ? doerrortrap+0x65/0x80 [ 1136.095543] ? __listdelentryvalidorreport.cold+0xf/0x6f [ 1136.101289] ? excinvalid_op+0x50/0x70 [ 1136.105127] ? __listdelentryvalidorreport.cold+0xf/0x6f [ 1136.110874] ? asmexcinvalidop+0x1a/0x20 [ 1136.115059] ? __listdelentryvalidorreport.cold+0xf/0x6f [ 1136.120806] movelinkedworks+0x4a/0xa0 [ 1136.124733] workerthread+0x216/0x3a0 [ 1136.128485] ? __pfxworkerthread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfxkthread+0x10/0x10 [ 1136.139657] retfrom_fork+0x31/0x50 [ 1136.143236] ? __pfxkthread+0x10/0x10 [ 1136.146988] retfromforkasm+0x1a/0x30 [ 1136.150915] </TASK>(CVE-2025-40261)

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

NFSD: Fix crash in nfsd4readrelease()

When tracing is enabled, the tracenfsdread_done trace point crashes during the pynfs read.testNoFh test.(CVE-2025-40324)

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

nfs4setupreaddir(): insufficient locking for ->dparent->dinode dereferencing

Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack.

Anyway, it's easy to deal with - since xdrencodehyper() is just a call of putunalignedbe64(), we can put that under ->d_lock and be done with that.(CVE-2025-68185)

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

timers: Fix NULL function pointer race in timershutdownsync()

There is a race condition between timershutdownsync() and timer expiration that can lead to hitting a WARNON in expiretimers().

The issue occurs when timershutdownsync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this:

CPU0 CPU1 <SOFTIRQ> locktimerbase() expiretimers() base->runningtimer = timer; unlocktimerbase() [calltimerfn enter] modtimer() ... timershutdownsync() locktimerbase() // For now, will not detach the timer but only clear its function to NULL if (base->runningtimer != timer) ret = detachifpending(timer, base, true); if (shutdown) timer->function = NULL; unlocktimerbase() [calltimerfn exit] locktimerbase() base->runningtimer = NULL; unlocktimerbase() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expiretimers() WARNONONCE(!fn) // hit ... locktimerbase() // Now timer will detach if (base->runningtimer != timer) ret = detachifpending(timer, base, true); if (shutdown) timer->function = NULL; unlocktimer_base()

The problem is that timershutdownsync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARNONONCE(!fn) check in expire_timers().

Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.(CVE-2025-68214)

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

usb: storage: Fix memory leak in USB bulk transport

A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355.

When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the USBULKCS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB.

Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase.

Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.(CVE-2025-68288)

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

ext4: xattr: fix null pointer deref in ext4rawinode()

If ext4getinodeloc() fails (e.g. if it returns -EFSCORRUPTED), iloc.bh will remain set to NULL. Since ext4xattrinodedecrefall() lacks error checking, this will lead to a null pointer dereference in ext4rawinode(), called right after ext4getinode_loc().

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-68820)

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

net: hns3: using the num_tqps in the vf driver to apply for resources

Currently, hdev->htqp is allocated using hdev->numtqps, and kinfo->tqp is allocated using kinfo->numtqps. However, kinfo->numtqps is set to min(newtqps, hdev->numtqps); Therefore, kinfo->numtqps may be smaller than hdev->numtqps, which causes some hdev->htqp[i] to remain uninitialized in hclgevfknic_setup().

Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps, ensuring that the lengths of hdev->htqp and kinfo->tqp are consistent and that all elements are properly initialized.(CVE-2025-71064)

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

macvlan: observe an RCU grace period in macvlancommonnewlink() error path

valis reported that a race condition still happens after my prior patch.

macvlancommonnewlink() might have made @dev visible before detecting an error, and its caller will directly call free_netdev(dev).

We must respect an RCU period, either in macvlan or the core networking stack.

After adding a temporary mdelay(1000) in macvlanforwardsource_one() to open the race window, valis repro was:

ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source

(ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 &) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes RTNETLINK answers: Invalid argument

BUG: KASAN: slab-use-after-free in macvlanforwardsource (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) Read of size 8 at addr ffff888016bb89c0 by task e/175

CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <IRQ> dumpstacklvl (lib/dumpstack.c:123) printreport (mm/kasan/report.c:379 mm/kasan/report.c:482) ? macvlanforwardsource (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) kasanreport (mm/kasan/report.c:597) ? macvlanforwardsource (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) macvlanforwardsource (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) ? taskletinit (kernel/softirq.c:983) macvlanhandleframe (drivers/net/macvlan.c:501)

Allocated by task 169: kasansavestack (mm/kasan/common.c:58) kasansavetrack (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) __kasan_kmalloc (mm/kasan/common.c:419) __kvmallocnodenoprof (./include/linux/kasan.h:263 mm/slub.c:5657 mm/slub.c:7140) allocnetdevmqs (net/core/dev.c:12012) rtnl_createlink (net/core/rtnetlink.c:3648) rtnlnewlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlinkrcvmsg (net/core/rtnetlink.c:6958) netlinkrcvskb (net/netlink/afnetlink.c:2550) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) _x64syssendto (net/socket.c:2209) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:131)

Freed by task 169: kasansavestack (mm/kasan/common.c:58) kasansavetrack (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) kasansavefree_info (mm/kasan/generic.c:587) __kasanslabfree (mm/kasan/common.c:287) kfree (mm/slub.c:6674 mm/slub.c:6882) rtnlnewlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlinkrcvmsg (net/core/rtnetlink.c:6958) netlinkrcvskb (net/netlink/afnetlink.c:2550) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) _x64syssendto (net/socket.c:2209) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:131)(CVE-2026-23273)

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

Bluetooth: L2CAP: Validate L2CAPINFORSP payload length before access

l2capinformationrsp() checks that cmdlen covers the fixed l2capinfo_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present:

• L2CAPITFEATMASK calls getunalignedle32(rsp->data), which reads 4 bytes past the header (needs cmdlen >= 8).

• L2CAPITFIXEDCHAN reads rsp->data[0], 1 byte past the header (needs cmdlen >= 5).

A truncated L2CAPINFORSP with result == L2CAPIRSUCCESS triggers an out-of-bounds read of adjacent skb data.

Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (featmask and remotefixedchan remain zero from kzalloc), so the info timer cleanup and l2capconn_start() still run and the connection is not stalled.(CVE-2026-31393)

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

ext4: reject mount if bigalloc with sfirstdata_block != 0

bigalloc with sfirstdata_block != 0 is not supported, reject mounting it.(CVE-2026-31447)

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

ksmbd: fix memory leaks and NULL deref in smb2_lock()

smb2lock() has three error handling issues after listdel() detaches smblock from locklist at nocheckcl:

1) If vfslockfile() returns an unexpected error in the non-UNLOCK path, goto out leaks smblock and its flock because the out: handler only iterates locklist and rollbacklist, neither of which contains the detached smblock.

2) If vfslockfile() returns -ENOENT in the UNLOCK path, goto out leaks smb_lock and flock for the same reason. The error code returned to the dispatcher is also stale.

3) In the rollback path, smbflockinit() can return NULL on allocation failure. The result is dereferenced unconditionally, causing a kernel NULL pointer dereference. Add a NULL check to prevent the crash and clean up the bookkeeping; the VFS lock itself cannot be rolled back without the allocation and will be released at file or connection teardown.

Fix cases 1 and 2 by hoisting the locksfreelock()/kfree() to before the if(!rc) check in the UNLOCK branch so all exit paths share one free site, and by freeing smblock and flock before goto out in the non-UNLOCK branch. Propagate the correct error code in both cases. Fix case 3 by wrapping the VFS unlock in an if(rlock) guard and adding a NULL check for locksfree_lock(rlock) in the shared cleanup.

Found via call-graph analysis using sqry.(CVE-2026-31477)

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

driver core: platform: use generic driver_override infrastructure

When a driver is probed through __driverattach(), the bus' match() callback is called without the device lock held, thus accessing the driveroverride field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from _driverattach() without the device lock held is intentional. 1

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

ksmbd: require 3 sub-authorities before reading sub_auth[2]

parsedacl() compares each ACE SID against sidunixNFSmode and on match reads sid.subauth[2] as the file mode. If sidunixNFSmode is the prefix S-1-5-88-3 with numsubauth = 2 then comparesids() compares only min(numsubauth, 2) sub-authorities so a client SID with numsubauth = 2 and sub_auth = {88, 3} will match.

If numsubauth = 2 and the ACE is placed at the very end of the security descriptor, subauth[2] will be 4 bytes past endofacl. The out-of-band bytes will then be masked to the low 9 bits and applied as the file's POSIX mode, probably not something that is good to have happen.

Fix this up by forcing the SID to actually carry a third sub-authority before reading it at all.(CVE-2026-31611)

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

ksmbd: validate EaNameLength in smb2getea()

smb2getea() reads ea_req->EaNameLength from the client request and passes it directly to strncmp() as the comparison length without verifying that the length of the name really is the size of the input buffer received.

Fix this up by properly checking the size of the name based on the value received and the overall size of the request, to prevent a later strncmp() call to use the length as a "trusted" size of the buffer. Without this check, uninitialized heap values might be slowly leaked to the client.(CVE-2026-31612)

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

ksmbd: use checkaddoverflow() to prevent u16 DACL size overflow

setposixaclentriesdacl() and setntacldacl() accumulate ACE sizes in u16 variables. When a file has many POSIX ACL entries, the accumulated size can wrap past 65535, causing the pointer arithmetic (char *)pndace + *size to land within already-written ACEs. Subsequent writes then overwrite earlier entries, and pndacl->size gets a truncated value.

Use checkaddoverflow() at each accumulation point to detect the wrap before it corrupts the buffer, consistent with existing checkmuloverflow() usage elsewhere in smbacl.c.(CVE-2026-31704)

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

smb: client: fix OOB read in smb2ioctlqueryinfo QUERYINFO path

smb2ioctlqueryinfo() has two response-copy branches: PASSTHRUFSCTL and the default QUERYINFO path. The QUERYINFO branch clamps qi.inputbufferlength to the server-reported OutputBufferLength and then copies qi.inputbufferlength bytes from qirsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rspiov[1].iov_len.

A malicious server can return OutputBufferLength larger than the actual QUERYINFO response, causing copyto_user() to walk past the response buffer and expose adjacent kernel heap to userspace.

Guard the QUERYINFO copy with a bounds check on the actual Buffer payload. Use structsize(qirsp, Buffer, qi.inputbuffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.(CVE-2026-31708)

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

usb: cdns3: gadget: fix state inconsistency on gadget init failure

When cdns3gadgetstart() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency.

When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role

The role state is not set to CDNSROLESTATEACTIVE due to the error, so cdnsrole_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles.

This leads to a synchronous external abort in xhcigensetup() when setting up the host controller:

[ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhcigensetup+0xa4/0x408 [ 1301.393391] backtrace: ... xhcigensetup+0xa4/0x408 <-- CRASH xhciplatsetup+0x44/0x58 usbaddhcd+0x284/0x678 ... cdnsroleset+0x9c/0xbc <-- Role switch

Fix by calling cdnsdrdgadget_off() in the error path to properly clean up the DRD gadget state.(CVE-2026-31754)

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

usb: cdns3: gadget: fix NULL pointer dereference in ep_queue

When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when _cdns3gadgetepqueue() is called, causing a kernel crash.

Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints.

This prevents potential crashes when ep_queue is called on endpoints that are not ready.(CVE-2026-31755)

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

Bluetooth: hci_event: move wake reason storage into validated event handlers

hcistorewakereason() is called from hcieventpacket() immediately after stripping the HCI event header but before hcieventfunc() enforces the per-event minimum payload length from hciev_table. This means a short HCI event frame can reach bacpy() before any bounds check runs.

Rather than duplicating skb parsing and per-event length checks inside hcistorewakereason(), move wake-address storage into the individual event handlers after their existing event-length validation has succeeded. Convert hcistorewakereason() into a small helper that only stores an already-validated bdaddr while the caller holds hcidevlock(). Use the same helper after hcieventfunc() with a NULL address to preserve the existing unexpected-wake fallback semantics when no validated event handler records a wake address.

Annotate the helper with _musthold(&hdev->lock) and add lockdepassertheld(&hdev->lock) so future call paths keep the lock contract explicit.

Call the helper from hciconnrequestevt(), hciconncompleteevt(), hcisyncconncompleteevt(), leconncompleteevt(), hcileadvreportevt(), hcileextadvreportevt(), hciledirectadvreportevt(), hcilepasyncestablishedevt(), and hcilepastreceivedevt().(CVE-2026-31771)

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

HID: multitouch: Check to ensure report responses match the request

It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes.

Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.(CVE-2026-43047)

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

HID: core: Mitigate potential OOB by removing bogus memset()

The memset() in hidreportraw_event() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution.

The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report.

Suggested-by Benjamin Tissoires <(CVE-2026-43048)

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

EFI/CPER: don't dump the entire memory region

The current logic at cperprintfw_err() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory.

The end result can be:

• the logic taking a lot of time dumping large regions of memory;
• data disclosure due to the memory dumps;
• an OOPS, if it tries to dump an unmapped memory region.

Fix it by checking if the section length is too small before doing a hex dump.

rjw: Subject tweaks

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

LoongArch: Make cpumaskofnode() robust against NUMANONODE

The arch definition of cpumaskofnode() cannot handle NUMANONODE - which is a valid index - so add a check for this.(CVE-2026-43212)

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

arm64: Add support for TSV110 Spectre-BHB mitigation

The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation.(CVE-2026-43261)

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

USB: core: Limit the length of unkillable synchronous timeouts

The usbcontrolmsg(), usbbulkmsg(), and usbinterruptmsg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device.

To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector.

In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.(CVE-2026-43428)

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

usb: xhci: Prevent interrupt storm on host controller error (HCE)

The xHCI controller reports a Host Controller Error (HCE) in UAS Storage Device plug/unplug scenarios on Android devices. HCE is checked in xhci_irq() function and causes an interrupt storm (since the interrupt isn’t cleared), leading to severe system-level faults.

When the xHC controller reports HCE in the interrupt handler, the driver only logs a warning and assumes xHC activity will stop as stated in xHCI specification. An interrupt storm does however continue on some hosts even after HCE, and only ceases after manually disabling xHC interrupt and stopping the controller by calling xhci_halt().

Add xhcihalt() to xhciirq() function where STSHCE status is checked, mirroring the existing error handling pattern used for STSFATAL errors.

This only fixes the interrupt storm. Proper HCE recovery requires resetting and re-initializing the xHC.(CVE-2026-43488)

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

ptrace: slightly saner 'get_dumpable()' logic

The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm.

And almost all users do in fact use it only for the case where the task has a mm pointer.

But we have one odd special case: ptracemayaccess() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACEMODEREAD_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads).

It's not what this flag was designed for, but it is what it is.

The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all.

Make it all make a bit more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAPSYSPTRACE capability to override.(CVE-2026-46333)