OESA-2026-2493

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

scsi: target: Fix recursive locking in __configfsopenfile()

In flushwritebuffer, &p->fragsem is acquired and then the loaded store function is called, which, here, is targetcoreitemdbrootstore(). This function called filpopen(), following which these functions were called (in reverse order), according to the call trace:

down_read __configfsopenfile dodentryopen vfsopen doopen pathopenat dofilpopen fileopenname filpopen targetcoreitemdbrootstore flushwritebuffer configfswriteiter

targetcoreitemdbrootstore() tries to validate the new file path by trying to open the file path provided to it; however, in this case, the bug report shows:

db_root: not a directory: /sys/kernel/config/target/dbroot

indicating that the same configfs file was tried to be opened, on which it is currently working on. Thus, it is trying to acquire fragsem semaphore of the same file of which it already holds the semaphore obtained in flushwrite_buffer(), leading to acquiring the semaphore in a nested manner and a possibility of recursive locking.

Fix this by modifying targetcoreitemdbrootstore() to use kernpath() instead of filpopen() to avoid opening the file using filesystem-specific function __configfsopenfile(), and further modifying it to make this fix compatible.(CVE-2026-23292)

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

scsi: core: Fix refcount leak for tagset_refcnt

This leak will cause a hang when tearing down the SCSI host. For example, iscsid hangs with the following call trace:

[130120.652718] scsiallocsdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured

PID: 2528 TASK: ffff9d0408974e00 CPU: 3 COMMAND: "iscsid" #0 [ffffb5b9c134b9e0] __schedule at ffffffff860657d4 #1 [ffffb5b9c134ba28] schedule at ffffffff86065c6f #2 [ffffb5b9c134ba40] schedule_timeout at ffffffff86069fb0 #3 [ffffb5b9c134bab0] __waitforcommon at ffffffff8606674f #4 [ffffb5b9c134bb10] scsiremovehost at ffffffff85bfe84b #5 [ffffb5b9c134bb30] iscsiswtcpsessiondestroy at ffffffffc03031c4 [iscsitcp] #6 [ffffb5b9c134bb48] iscsiifrecvmsg at ffffffffc0292692 [scsitransportiscsi] #7 [ffffb5b9c134bb98] iscsiifrx at ffffffffc02929c2 [scsitransportiscsi] #8 [ffffb5b9c134bbf0] netlinkunicast at ffffffff85e551d6 #9 [ffffb5b9c134bc38] netlinksendmsg at ffffffff85e554ef(CVE-2026-23296)

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

i40e: Fix preempt count leak in napi poll tracepoint

Using getcpu() in the tracepoint assignment causes an obvious preempt count leak because nothing invokes putcpu() to undo it:

softirq: huh, entered softirq 3 NETRX with preemptcount 00000100, exited with 00000101?

This clearly has seen a lot of testing in the last 3+ years...

Use smpprocessorid() instead.(CVE-2026-23313)

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

drm/vmwgfx: Return the correct value in vmwtranslateptr functions

Before the referenced fixes these functions used a lookup function that returned a pointer. This was changed to another lookup function that returned an error code with the pointer becoming an out parameter.

The error path when the lookup failed was not changed to reflect this change and the code continued to return the PTRERR of the now uninitialized pointer. This could cause the vmwtranslate_ptr functions to return success when they actually failed causing further uninitialized and OOB accesses.(CVE-2026-23317)

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

x86/efi: defer freeing of boot services memory

efifreebootservices() frees memory occupied by EFIBOOTSERVICESCODE and EFIBOOTSERVICESDATA using memblockfree_late().

There are two issue with that: memblockfreelate() should be used for memory allocated with memblockalloc() while the memory reserved with memblockreserve() should be freed with freereservedarea().

More acutely, with CONFIGDEFERREDSTRUCTPAGEINIT=y efifreeboot_services() is called before deferred initialization of the memory map is complete.

Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM.

If the freed memory resides in the areas that memory map for them is still uninitialized, they won't be actually freed because memblockfreelate() calls memblockfreepages() and the latter skips uninitialized pages.

Using freereservedarea() at this point is also problematic because _freepage() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map.

Delaying the entire efifreeboot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that's undesirable late in boot when there is concurrency.

More robust approach is to only defer freeing of the EFI boot services memory.

Split efifreebootservices() in two. First efiunmapbootservices() collects ranges that should be freed into an array then efifreeboot_services() later frees them after deferred init is complete.(CVE-2026-23352)

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

nvme: fix admin queue leak on controller reset

When nvmeallocadmintagset() is called during a controller reset, a previous admin queue may still exist. Release it properly before allocating a new one to avoid orphaning the old queue.

This fixes a regression introduced by commit 03b3bcd319b3 ("nvme: fix admin request_queue lifetime").(CVE-2026-23360)

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

blktrace: fix __thiscpuread/write in preemptible context

tracingrecordcmdline() internally uses __thiscpuread() and _thiscpuwrite() on the per-CPU variable tracecmdlinesave, and tracesavecmdline() explicitly asserts preemption is disabled via lockdepassertpreemptiondisabled(). These operations are only safe when preemption is off, as they were designed to be called from the scheduler context (probewakeupschedswitch() / probewakeup()).

_blkaddtrace() was calling tracingrecordcmdline(current) early in the blktracer path, before ring buffer reservation, from process context where preemption is fully enabled. This triggers the following using blktests/blktrace/002:

blktrace/002 (blktrace ftrace corruption with sysfs trace) [failed] runtime 0.367s ... 0.437s something found in dmesg: [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] null_blk: disk nullb1 created [ 81.357294] BUG: using __thiscpuread() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracingrecordcmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] <TASK> [ 81.362886] dumpstacklvl+0x8d/0xb0 ... (See '/mnt/sda/blktests/results/nodev/blktrace/002.dmesg' for the entire message)

[ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] null_blk: disk nullb1 created [ 81.357294] BUG: using __thiscpuread() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracingrecordcmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] <TASK> [ 81.362886] dumpstacklvl+0x8d/0xb0 [ 81.362895] checkpreemptiondisabled+0xce/0xe0 [ 81.362902] tracingrecordcmdline+0x10/0x40 [ 81.362923] __blkaddtrace+0x307/0x5d0 [ 81.362934] ? lock_acquire+0xe0/0x300 [ 81.362940] ? ioviterextractpages+0x101/0xa30 [ 81.362959] blkaddtracebio+0x106/0x1e0 [ 81.362968] submitbionoacctnocheck+0x24b/0x3a0 [ 81.362979] ? lockdepinitmaptype+0x58/0x260 [ 81.362988] submitbiowait+0x56/0x90 [ 81.363009] __blkdevdirectIO_simple+0x16c/0x250 [ 81.363026] ? _pfxsubmitbiowaitendio+0x10/0x10 [ 81.363038] ? rcureadlockanyheld+0x73/0xa0 [ 81.363051] blkdevreaditer+0xc1/0x140 [ 81.363059] vfsread+0x20b/0x330 [ 81.363083] ksysread+0x67/0xe0 [ 81.363090] dosyscall64+0xbf/0xf00 [ 81.363102] entrySYSCALL64afterhwframe+0x76/0x7e [ 81.363106] RIP: 0033:0x7f281906029d [ 81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec [ 81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIGRAX: 0000000000000000 [ 81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d [ 81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000 [ 81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000 [ 81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000 [ 81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a [ 81.363142] </TASK>

The same BUG fires from blkaddtraceplug(), blkaddtraceunplug(), and blkaddtrace_rq() paths as well.

The purpose of tracin ---truncated---(CVE-2026-23374)

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

bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing

struct bpf_plt contains a u64 target field. Currently, the BPF JIT allocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT buffer.

Because the base address of the JIT buffer can be 4-byte aligned (e.g., ending in 0x4 or 0xc), the relative padding logic in build_plt() fails to ensure that target lands on an 8-byte boundary.

This leads to two issues: 1. UBSAN reports misaligned-access warnings when dereferencing the structure. 2. More critically, target is updated concurrently via WRITEONCE() in bpfarchtextpoke() while the JIT'd code executes ldr. On arm64, 64-bit loads/stores are only guaranteed to be single-copy atomic if they are 64-bit aligned. A misaligned target risks a torn read, causing the JIT to jump to a corrupted address.

Fix this by increasing the allocation alignment requirement to 8 bytes (sizeof(u64)) in bpfjitbinarypackalloc(). This anchors the base of the JIT buffer to an 8-byte boundary, allowing the relative padding math in build_plt() to correctly align the target field.(CVE-2026-23383)

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

udp: Fix wildcard bind conflict check when using hash2

When binding a udp_sock to a local address and port, UDP uses two hashes (udptable->hash and udptable->hash2) for collision detection. The current code switches to "hash2" when hslot->count > 10.

"hash2" is keyed by local address and local port. "hash" is keyed by local port only.

The issue can be shown in the following bind sequence (pseudo code):

bind(fd1, "[fd00::1]:8888") bind(fd2, "[fd00::2]:8888") bind(fd3, "[fd00::3]:8888") bind(fd4, "[fd00::4]:8888") bind(fd5, "[fd00::5]:8888") bind(fd6, "[fd00::6]:8888") bind(fd7, "[fd00::7]:8888") bind(fd8, "[fd00::8]:8888") bind(fd9, "[fd00::9]:8888") bind(fd10, "[fd00::10]:8888")

/* Correctly return -EADDRINUSE because "hash" is used * instead of "hash2". udpliblportinuse() detects the * conflict. */ bind(failfd, "[::]:8888")

/* After one more socket is bound to "[fd00::11]:8888", * hslot->count exceeds 10 and "hash2" is used instead. / bind(fd11, "[fd00::11]:8888") bind(fail_fd, "[::]:8888") / succeeds unexpectedly */

The same issue applies to the IPv4 wildcard address "0.0.0.0" and the IPv4-mapped wildcard address "::ffff:0.0.0.0". For example, if there are existing sockets bound to "192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or "[::ffff:0.0.0.0]:8888" can also miss the conflict when hslot->count > 10.

TCP inetcskgetport() already has the correct check in inetusebhash2onbind(). Rename it to inetusehash2onbind() and move it to inethashtables.h so udp.c can reuse it in this fix.(CVE-2026-31503)

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

bridge: brndsend: validate ND option lengths

brndsend() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.

Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.(CVE-2026-31752)

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

xfs: close crash window in attr dabtree inactivation

When inactivating an inode with node-format extended attributes, xfsattr3nodeinactive() invalidates all child leaf/node blocks via xfstransbinval(), but intentionally does not remove the corresponding entries from their parent node blocks. The implicit assumption is that xfsattr_inactive() will truncate the entire attr fork to zero extents afterwards, so log recovery will never reach the root node and follow those stale pointers.

However, if a log shutdown occurs after the leaf/node block cancellations commit but before the attr bmap truncation commits, this assumption breaks. Recovery replays the attr bmap intact (the inode still has attr fork extents), but suppresses replay of all cancelled leaf/node blocks, maybe leaving them as stale data on disk. On the next mount, xlogrecoverprocess_iunlinks() retries inactivation and attempts to read the root node via the attr bmap. If the root node was not replayed, reading the unreplayed root block triggers a metadata verification failure immediately; if it was replayed, following its child pointers to unreplayed child blocks triggers the same failure:

XFS (pmem0): Metadata corruption detected at xfsda3nodereadverify+0x53/0x220, xfsda3node block 0x78 XFS (pmem0): Unmount and run xfsrepair XFS (pmem0): First 128 bytes of corrupted metadata buffer: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ XFS (pmem0): metadata I/O error in "xfsdareadbuf+0x104/0x190" at daddr 0x78 len 8 error 117

Fix this in two places:

In xfsattr3nodeinactive(), after calling xfstransbinval() on a child block, immediately remove the entry that references it from the parent node in the same transaction. This eliminates the window where the parent holds a pointer to a cancelled block. Once all children are removed, the now-empty root node is converted to a leaf block within the same transaction. This node-to-leaf conversion is necessary for crash safety. If the system shutdown after the empty node is written to the log but before the second-phase bmap truncation commits, log recovery will attempt to verify the root block on disk. xfsda3nodeverify() does not permit a node block with count == 0; such a block will fail verification and trigger a metadata corruption shutdown. on the other hand, leaf blocks are allowed to have this transient state.

In xfsattrinactive(), split the attr fork truncation into two explicit phases. First, truncate all extents beyond the root block (the child extents whose parent references have already been removed above). Second, invalidate the root block and truncate the attr bmap to zero in a single transaction. The two operations in the second phase must be atomic: as long as the attr bmap has any non-zero length, recovery can follow it to the root block, so the root block invalidation must commit together with the bmap-to-zero truncation.(CVE-2026-43053)

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

scsi: target: tcmloop: Drain commands in targetreset handler

tcmlooptargetreset() violates the SCSI EH contract: it returns SUCCESS without draining any in-flight commands. The SCSI EH documentation (scsieh.rst) requires that when a reset handler returns SUCCESS the driver has made lower layers "forget about timed out scmds" and is ready for new commands. Every other SCSI LLD (virtioscsi, mpt3sas, ipr, scsidebug, mpi3mr) enforces this by draining or completing outstanding commands before returning SUCCESS.

Because tcmlooptargetreset() doesn't drain, the SCSI EH reuses in-flight scsicmnd structures for recovery commands (e.g. TUR) while the target core still has async completion work queued for the old secmd. The memset in queuecommand zeroes selun and lunrefactive, causing transportlunremovecmd() to skip its percpurefput(). The leaked LUN reference prevents transportclearlunref() from completing, hanging configfs LUN unlink forever in D-state:

INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transportclearlunref+0x78/0x90 [targetcoremod] coretpgremovelun+0x28/0xb0 [targetcoremod] targetfabricportunlink+0x50/0x60 [targetcoremod] configfsunlink+0x156/0x1f0 [configfs] vfsunlink+0x109/0x290 dounlinkat+0x1d5/0x2d0

Fix this by making tcmlooptarget_reset() actually drain commands:

1. Issue TMRLUNRESET via tcmloopissuetmr() to drain all commands that the target core knows about (those not yet CMDT_COMPLETE).

2. Use blkmqtagsetbusyiter() to iterate all started requests and flushwork() on each secmd — this drains any deferred completion work for commands that already had CMDTCOMPLETE set before the TMR (which the TMR skips via __targetcheckiostate()). This is the same pattern used by mpi3mr, scsidebug, and libsas to drain outstanding commands during reset.(CVE-2026-43054)

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

net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback

NETIFFIPV6_CSUM only advertises support for checksum offload of packets without IPv6 extension headers. Packets with extension headers must fall back onto software checksumming. Since TSO depends on checksum offload, those must revert to GSO.

The below commit introduces that fallback. It always checks network header length. For tunneled packets, the inner header length must be checked instead. Extend the check accordingly.

A special case is tunneled packets without inner IP protocol. Such as RFC 6951 SCTP in UDP. Those are not standard IPv6 followed by transport header either, so also must revert to the software GSO path.(CVE-2026-43057)

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

Bluetooth: hcisync: annotate data-races around hdev->reqstatus

_hcicmdsyncsk() sets hdev->reqstatus under hdev->reqlock:

hdev->req_status = HCI_REQ_PEND;

However, several other functions read or write hdev->req_status without holding any lock:

• hcisendcmdsync() reads reqstatus in hcicmdwork (workqueue)
• hcicmdsync_complete() reads/writes from HCI event completion
• hcicmdsynccancel() / hcicmdsynccancel_sync() read/write
• hciabortconn() reads in connection abort path

Since _hcicmdsyncsk() runs on hdev->reqworkqueue while hcisendcmdsync() runs on hdev->workqueue, these are different workqueues that can execute concurrently on different CPUs. The plain C accesses constitute a data race.

Add READONCE()/WRITEONCE() annotations on all concurrent accesses to hdev->reqstatus to prevent potential compiler optimizations that could affect correctness (e.g., load fusing in the waitevent condition or store reordering).(CVE-2026-43119)

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

fbcon: check return value of con2fbacquirenewinfo()

If fbconopen() fails when called from con2fbacquirenewinfo() then info->fbconpar pointer remains NULL which is later dereferenced.

Add check for return value of the function con2fbacquirenewinfo() to avoid it.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2026-43123)

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

Bluetooth: L2CAP: Fix missing key size check for L2CAPLECONN_REQ

This adds a check for encryption key size upon receiving L2CAPLECONNREQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAPCRLEBADKEYSIZE.(CVE-2026-43134)

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

Revert "PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"

This reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"), which causes a deadlock by recursively taking pcirescanremovelock when sriovdelvfs() is called as part of pcistopandremovebusdevice(). For example with the following sequence of commands:

$ echo <NUM> > /sys/bus/pci/devices/<pf>/sriov_numvfs $ echo 1 > /sys/bus/pci/devices/<pf>/remove

A trimmed trace of the deadlock on a mlx5 device is as below:

zsh/5715 is trying to acquire lock: 000002597926ef50 (pcirescanremovelock){+.+.}-{3:3}, at: sriovdisable+0x34/0x140

but task is already holding lock: 000002597926ef50 (pcirescanremovelock){+.+.}-{3:3}, at: pcistopandremovebusdevicelocked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dumpstacklvl+0xc0/0x110 [<00000259779c844e>] printdeadlock_bug+0x31e/0x330 [<00000259779c1908>] __lockacquire+0x16c8/0x32f0 [<00000259779bffac>] lockacquire+0x14c/0x350 [<00000259789643a6>] __mutexlockcommon+0xe6/0x1520 [<000002597896413c>] mutexlocknested+0x3c/0x50 [<00000259784a07e4>] sriovdisable+0x34/0x140 [<00000258f7d6dd80>] mlx5sriovdisable+0x50/0x80 [mlx5core] [<00000258f7d5745e>] removeone+0x5e/0xf0 [mlx5core] [<00000259784857fc>] pcideviceremove+0x3c/0xa0 [<000002597851012e>] devicereleasedriverinternal+0x18e/0x280 [<000002597847ae22>] pcistopbusdevice+0x82/0xa0 [<000002597847afce>] pcistopandremovebusdevicelocked+0x5e/0x80 [<00000259784972c2>] removestore+0x72/0x90 [<0000025977e6661a>] kernfsfopwriteiter+0x15a/0x200 [<0000025977d7241c>] vfswrite+0x24c/0x300 [<0000025977d72696>] ksyswrite+0x86/0x110 [<000002597895b61c>] __dosyscall+0x14c/0x400 [<000002597896e0ee>] systemcall+0x6e/0x90

This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on.(CVE-2026-43147)

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

usb: dwc3: gadget: Move vbus draw to workqueue context

Currently dwc3gadgetvbus_draw() can be called from atomic context, which in turn invokes power-supply-core APIs. And some these PMIC APIs have operations that may sleep, leading to kernel panic.

Fix this by moving the vbus_draw into a workqueue context.(CVE-2026-43170)

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

media: pvrusb2: fix URB leak in pvr2sendrequest_ex

When pvr2sendrequestex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2sendrequestex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usbsubmiturb().

Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails.(CVE-2026-43223)

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:

kexec: derive purgatory entry from symbol

kexecloadpurgatory() derives image->start by locating eentry inside an SHFEXECINSTR section. If the purgatory object contains multiple executable sections with overlapping sh_addr, the entrypoint check can match more than once and trigger a WARN.

Derive the entry section from the purgatorystart symbol when present and compute image->start from its final placement. Keep the existing eentry fallback for purgatories that do not expose the symbol.

WARNING: kernel/kexecfile.c:1009 at kexecloadpurgatory+0x395/0x3c0, CPU#10: kexec/1784 Call Trace: <TASK> bzImage64load+0x133/0xa00 __dosyskexecfileload+0x2b3/0x5c0 dosyscall64+0x81/0x610 entrySYSCALL64afterhwframe+0x76/0x7e

[(CVE-2026-43289)

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

perf/x86/intel/uncore: Fix die ID init and look up bugs

In snbeppci2phymapinit(), in the nrnodeids > 8 path, uncoredevicetodie() may return -1 when all CPUs associated with the UBOX device are offline.

Remove the WARNONONCE(die_id == -1) check for two reasons:

• The current code breaks out of the loop. This is incorrect because pcigetdevice() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan.

• Returning -EINVAL is incorrect, since marking offline buses with die_id == -1 is expected and should not be treated as an error.

Separately, when NUMA is disabled on a NUMA-capable platform, pcibustonode() returns NUMANONODE, causing uncoredevicetodie() to return -1 for all PCI devices. As a result, sprupdatedevicelocation(), used on Intel SPR and EMR, ignores the corresponding PMON units and does not add them to the RB tree.

Fix this by using uncorepcibustodieid(), which retrieves topology from the UBOX GIDNIDMAP register and works regardless of whether NUMA is enabled in Linux. This requires snbeppci2phymapinit() to be added in spruncorepci_init().

Keep uncoredevicetodie() only for the nrnode_ids > 8 case, where NUMA is expected to be enabled.(CVE-2026-43344)

The Linux kernel Nouveau graphics driver has a race condition/null pointer dereference issue in DPCD (DisplayPort Configuration Data) AUX channel transmission processing. When the GPU device enters the suspend state due to runtime power management (runtime PM), if the user space program (such as through the /dev/drmdp interface) attempts to initiate an AUX transfer request, the driver will try to access the GSP (Graphics System Processor) firmware code of the suspended device, causing the kernel to crash.(CVE-2026-43381)

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

ceph: add a bunch of missing cephpathinfo initializers

cephmdscbuildpath() must be called with a zero-initialized cephpathinfo parameter, or else the following cephmdscfreepath_info() may crash.

Example crash (on Linux 6.18.12):

virttocache: Object is not a Slab page! WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6732 kmemcachefree+0x316/0x400 [...] Call Trace: [...] cephopen+0x13d/0x3e0 dodentryopen+0x134/0x480 vfsopen+0x2a/0xe0 pathopenat+0x9a3/0x1160 [...] cachefromobj: Wrong slab cache. namescache but object is from cephinodeinfo WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6746 kmemcachefree+0x2dd/0x400 [...] kernel BUG at mm/slub.c:634! Oops: invalid opcode: 0000 [#1] SMP NOPTI RIP: 0010:_slabfree+0x1a4/0x350

Some of the cephmdscbuildpath() callers had initializers, but others had not, even though they were all added by commit 15f519e9f883 ("ceph: fix race condition validating rparent before applying state"). The ones without initializer are suspectible to random crashes. (I can imagine it could even be possible to exploit this bug to elevate privileges.)

Unfortunately, these Ceph functions are undocumented and its semantics can only be derived from the code. I see that cephmdscbuild_path() initializes the structure only on success, but not on error.

Calling cephmdscfreepathinfo() after a failed cephmdscbuild_path() call does not even make sense, but that's what all callers do, and for it to be safe, the structure must be zero-initialized. The least intrusive approach to fix this is therefore to add initializers everywhere.(CVE-2026-43408)

In the Linux kernel, the following vulnerability has been resolved: powerpc, perf: Check that current->mm is alive before getting user callchain. It may happen that mm is already released, which leads to kernel panic. This adds the NULL check for current->mm, similarly to commit 20afc60f892d ("x86, perf: Check that current->mm is alive before getting user callchain"). I was getting this panic when running a profiling BPF program (profile.py from bcc-tools). In addition, move storing the top-level stack entry to generic perfcallchainuser to make sure the top-level entry is always captured, even if current->mm is NULL.(CVE-2026-43416)

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

usb: class: cdc-wdm: fix reordering issue in read code path

Quoting the bug report:

Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdmread() can see the new length and call copyto_user() on uninitialized memory. This also violates LKMM data race rules [1].

Fix it by using WRITE_ONCE and memory barriers.(CVE-2026-43427)

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

nfs: return EISDIR on nfs3proccreate if d_alias is a dir

If we found an alias through nfs3docreate/nfsaddorobtain /dsplice_alias which happens to be a dir dentry, we don't return any error, and simply forget about this alias, but the original dentry we were adding and passed as parameter remains negative.

This later causes an oops on nfsatomicopenv23/finishopen since we supply a negative dentry to dodentryopen.

This has been observed running lustre-racer, where dirs and files are created/removed concurrently with the same name and O_EXCL is not used to open files (frequent file redirection).

While dsplicealias typically returns a directory alias or NULL, we explicitly check disdir() to ensure that we don't attempt to perform file operations (like finish_open) on a directory inode, which triggers the observed oops.(CVE-2026-43470)

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

unshare: fix unshare_fs() handling

There's an unpleasant corner case in unshare(2), when we have a CLONENEWNS in flags and current->fs hadn't been shared at all; in that case copymnt_ns() gets passed current->fs instead of a private copy, which causes interesting warts in proof of correctness]

> I guess if private means fs->users == 1, the condition could still be true.

Unfortunately, it's worse than just a convoluted proof of correctness. Consider the case when we have CLONENEWCGROUP in addition to CLONENEWNS (and current->fs->users == 1).

We pass current->fs to copymntns(), all right. Suppose it succeeds and flips current->fs->{pwd,root} to corresponding locations in the new namespace. Now we proceed to copycgroupns(), which fails (e.g. with -ENOMEM). We call putmntns() on the namespace created by copymntns(), it's destroyed and its mount tree is dissolved, but... current->fs->root and current->fs->pwd are both left pointing to now detached mounts.

They are pinning those, so it's not a UAF, but it leaves the calling process with unshare(2) failing with -ENOMEM and leaving it with pwd and root on detached isolated mounts. The last part is clearly a bug.

There is other fun related to that mess (races with pivotroot(), including the one between pivotroot() and fork(), of all things), but this one is easy to isolate and fix - treat CLONENEWNS as "allocate a new fsstruct even if it hadn't been shared in the first place". Sure, we could go for something like "if both CLONENEWNS and one of the things that might end up failing after copymntns() call in createnewnamespaces() are set, force allocation of new fsstruct", but let's keep it simple - the cost of copyfsstruct() is trivial.

Another benefit is that copymntns() with CLONENEWNS always gets a freshly allocated fsstruct, yet to be attached to anything. That seriously simplifies the analysis...

FWIW, that bug had been there since the introduction of unshare(2) ;-/(CVE-2026-43472)

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

KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated

Explicitly set/clear CR8 write interception when AVIC is (de)activated to fix a bug where KVM leaves the interception enabled after AVIC is activated. E.g. if KVM emulates INIT=>WFS while AVIC is deactivated, CR8 will remain intercepted in perpetuity.

On its own, the dangling CR8 intercept is "just" a performance issue, but combined with the TPR sync bug fixed by commit d02e48830e3f ("KVM: SVM: Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active"), the danging intercept is fatal to Windows guests as the TPR seen by hardware gets wildly out of sync with reality.

Note, VMX isn't affected by the bug as TPRTHRESHOLD is explicitly ignored when Virtual Interrupt Delivery is enabled, i.e. when APICv is active in KVM's world. I.e. there's no need to trigger updatecr8_intercept(), this is firmly an SVM implementation flaw/detail.

WARN if KVM gets a CR8 write #VMEXIT while AVIC is active, as KVM should never enter the guest with AVIC enabled and CR8 writes intercepted.

Squash fix to avicdeactivatevmcb. - Paolo

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

lib/crypto: mpi: Fix integer underflow in mpireadrawfromsgl()

Yiming reports an integer underflow in mpireadrawfromsgl() when subtracting "lzeros" from the unsigned "nbytes".

For this to happen, the scatterlist "sgl" needs to occupy more bytes than the "nbytes" parameter and the first "nbytes + 1" bytes of the scatterlist must be zero. Under these conditions, the while loop iterating over the scatterlist will count more zeroes than "nbytes", subtract the number of zeroes from "nbytes" and cause the underflow.

When commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originally introduced the bug, it couldn't be triggered because all callers of mpireadrawfromsgl() passed a scatterlist whose length was equal to "nbytes".

However since commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto interface without scatterlists"), the underflow can now actually be triggered. When invoking a KEYCTLPKEYENCRYPT system call with a larger "outlen" than "inlen" and filling the "in" buffer with zeroes, cryptoakciphersyncprep() will create an all-zero scatterlist used for both the "src" and "dst" member of struct akcipherrequest and thereby fulfil the conditions to trigger the bug:

syskeyctl() keyctlpkeyeds() asymmetrickeyedsop() softwarekeyedsop() cryptoakciphersyncencrypt() cryptoakciphersyncprep() cryptoakcipherencrypt() rsaenc() mpireadrawfromsgl()

To the user this will be visible as a DoS as the kernel spins forever, causing soft lockup splats as a side effect.

Fix it.(CVE-2026-43492)