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

KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation

Commit cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01.

As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB.

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

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

Bluetooth: l2cap: Add missing chan lock in l2capecredreconfrsp

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

zram: fix use-after-free in zrambvecwritepartial()

zramreadpage() picks the sync or async backing device read path based on whether the parent bio is NULL. zrambvecwritepartial() passes its parent bio down, so for ZRAMWB slots the read is dispatched asynchronously and zramreadpage() returns 0 while the bio is still in flight. The caller then runs memcpyfrombvec(), zramwritepage() and freepage() on the buffer, leaving the async read to write into a freed page.

zrambvecreadpartial() was switched to NULL in commit 4e3c87b9421d ("zram: fix synchronous reads") for the same reason; the writepartial counterpart was missed.

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

RDMA/mana: Validate rxhashkeylen

Sashiko points out that rxhashkeylen comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow.

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

RDMA/vmwpvrdma: Fix double free on pvrdmaallocucontext() error path

Sashiko points out that pvrdmauarfree() is already called within pvrdmadeallocucontext(), so calling it before triggers a double free.

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

PM: hibernate: Avoid deadlock in hibernatecompressorparamset()

syzbot reported a deadlock in locksystemsleep() (see below).

The write operation to "/sys/module/hibernate/parameters/compressor" conflicts with the registration of ieee80211 device, resulting in a deadlock when attempting to acquire systemtransitionmutex under paramlock.

To avoid this deadlock, change hibernatecompressorparamset() to use mutextrylock() for attempting to acquire systemtransitionmutex and return -EBUSY when it fails.

Task flags need not be saved or adjusted before calling mutextrylock(&systemtransitionmutex) because the caller is not going to end up waiting for this mutex and if it runs concurrently with system suspend in progress, it will be frozen properly when it returns to user space.

syzbot report:

syz-executor895/5833 is trying to acquire lock: ffffffff8e0828c8 (systemtransitionmutex){+.+.}-{4:4}, at: locksystemsleep+0x87/0xa0 kernel/power/main.c:56

but task is already holding lock: ffffffff8e07dc68 (paramlock){+.+.}-{4:4}, at: kernelparamlock kernel/params.c:607 [inline] ffffffff8e07dc68 (paramlock){+.+.}-{4:4}, at: paramattrstore+0xe6/0x300 kernel/params.c:586

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #3 (paramlock){+.+.}-{4:4}: mutexlockcommon kernel/locking/mutex.c:585 [inline] mutexlock+0x19b/0xb10 kernel/locking/mutex.c:730 ieee80211ratecontrolopsget net/mac80211/rate.c:220 [inline] ratecontrolalloc net/mac80211/rate.c:266 [inline] ieee80211initratectrlalg+0x18d/0x6b0 net/mac80211/rate.c:1015 ieee80211registerhw+0x20cd/0x4060 net/mac80211/main.c:1531 mac80211hwsimnewradio+0x304e/0x54e0 drivers/net/wireless/virtual/mac80211hwsim.c:5558 initmac80211hwsim+0x432/0x8c0 drivers/net/wireless/virtual/mac80211hwsim.c:6910 dooneinitcall+0x128/0x700 init/main.c:1257 doinitcalllevel init/main.c:1319 [inline] doinitcalls init/main.c:1335 [inline] dobasicsetup init/main.c:1354 [inline] kernelinitfreeable+0x5c7/0x900 init/main.c:1568 kernelinit+0x1c/0x2b0 init/main.c:1457 retfromfork+0x45/0x80 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244

-> #2 (rtnlmutex){+.+.}-{4:4}: mutexlockcommon kernel/locking/mutex.c:585 [inline] mutexlock+0x19b/0xb10 kernel/locking/mutex.c:730 wgpmnotification drivers/net/wireguard/device.c:80 [inline] wgpmnotification+0x49/0x180 drivers/net/wireguard/device.c:64 notifiercallchain+0xb7/0x410 kernel/notifier.c:85 notifiercallchainrobust kernel/notifier.c:120 [inline] blockingnotifiercallchainrobust kernel/notifier.c:345 [inline] blockingnotifiercallchainrobust+0xc9/0x170 kernel/notifier.c:333 pmnotifiercallchainrobust+0x27/0x60 kernel/power/main.c:102 snapshotopen+0x189/0x2b0 kernel/power/user.c:77 miscopen+0x35a/0x420 drivers/char/misc.c:179 chrdevopen+0x237/0x6a0 fs/chardev.c:414 dodentryopen+0x735/0x1c40 fs/open.c:956 vfsopen+0x82/0x3f0 fs/open.c:1086 doopen fs/namei.c:3830 [inline] pathopenat+0x1e88/0x2d80 fs/namei.c:3989 dofilpopen+0x20c/0x470 fs/namei.c:4016 dosysopenat2+0x17a/0x1e0 fs/open.c:1428 dosysopen fs/open.c:1443 [inline] dosysopenat fs/open.c:1459 [inline] sesysopenat fs/open.c:1454 [inline] x64sysopenat+0x175/0x210 fs/open.c:1454 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

-> #1 ((pmchainhead).rwsem){++++}-{4:4}: downread+0x9a/0x330 kernel/locking/rwsem.c:1524 blockingnotifiercallchainrobust kerne ---truncated---

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

fs/smb/client: fix out-of-bounds read in cifssanitizeprepath

When cifssanitizeprepath is called with an empty string or a string containing only delimiters (e.g., "/"), the current logic attempts to check (cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read.

This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL.

The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.

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

wifi: ath12k: fix memory leak in ath12kservicereadyextevent

Currently, in ath12kservicereadyextevent(), svcrdyext.macphycaps is not freed in the failure case, causing a memory leak. The following trace is observed in kmemleak:

unreferenced object 0xffff8b3eb5789c00 (size 1024): comm "softirq", pid 0, jiffies 4294942577 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 7b 00 00 10 ............{... 01 00 00 00 00 00 00 00 01 00 00 00 1f 38 00 00 .............8.. backtrace (crc 44e1c357): kmallocnoprof+0x30b/0x410 ath12kwmimacphycapsparse+0x84/0x100 [ath12k] ath12kwmitlviter+0x5e/0x140 [ath12k] ath12kwmisvcrdyextparse+0x308/0x4c0 [ath12k] ath12kwmitlviter+0x5e/0x140 [ath12k] ath12kservicereadyextevent.isra.0+0x44/0xd0 [ath12k] ath12kwmioprx+0x2eb/0xd70 [ath12k] ath12khtcrxcompletionhandler+0x1f4/0x330 [ath12k] ath12kcerecvprocesscb+0x218/0x300 [ath12k] ath12kpciceworkqueue+0x1b/0x30 [ath12k] processonework+0x219/0x680 bhworker+0x198/0x1f0 taskletaction+0x13/0x30 handlesoftirqs+0xca/0x460 irqexitrcu+0xbe/0x110 irqexitrcu+0x9/0x30

Free svcrdyext.macphycaps in the error case to fix this memory leak.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPLSILICONZ-1

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

Bluetooth: l2cap: Check encryption key size on incoming connection

This is required for passing GAP/SEC/SEM/BI-04-C PTS test case: Security Mode 4 Level 4, Responder - Invalid Encryption Key Size - 128 bit

This tests the security key with size from 1 to 15 bytes while the Security Mode 4 Level 4 requests 16 bytes key size.

Currently PTS fails with the following logs: - expected:Connection Response: Code: [3 (0x03)] Code Identifier: (lt)WildCard: Exists(gt) Length: [8 (0x0008)] Destination CID: (lt)WildCard: Exists(gt) Source CID: [64 (0x0040)] Result: [3 (0x0003)] Connection refused - Security block Status: (lt)WildCard: Exists(gt), but received:Connection Response: Code: [3 (0x03)] Code Identifier: [1 (0x01)] Length: [8 (0x0008)] Destination CID: [64 (0x0040)] Source CID: [64 (0x0040)] Result: [0 (0x0000)] Connection Successful Status: [0 (0x0000)] No further information available

And HCI logs: < HCI Command: Read Encrypti.. (0x05|0x0008) plen 2 Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 1 Status: Success (0x00) Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) Key size: 7 ACL Data RX: Handle 14 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 1 len 4 PSM: 4097 (0x1001) Source CID: 64 < ACL Data TX: Handle 14 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 1 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000)

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

wifi: rt2x00usb: 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 USB anchor lifetime so that it is released on driver unbind.

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

NFC: nxp-nci: allow GPIOs to sleep

Allow the firmware and enable GPIOs to sleep.

This fixes a WARNON' and allows the driver to operate GPIOs which are connected to I2C GPIO expanders.

-- >8 -- kernel: WARNING: CPU: 3 PID: 2636 at drivers/gpio/gpiolib.c:3880 gpiodsetvalue+0x88/0x98 -- >8 --

drm/i915/gt: Check setdefaultsubmission() before deferencing

HID: asus: avoid memory leak in asusreportfixup()

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

nvme-pci: ensure we're polling a polled queue

A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.

HID: magicmouse: avoid memory leak in magicmousereportfixup()

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

module: Fix kernel panic when a symbol stshndx is out of bounds

The module loader doesn't check for bounds of the ELF section index in simplifysymbols():

for (i = 1; i < symsec->shsize / sizeof(ElfSym); i++) { const char name = info->strtab + sym[i].stname;

switch (sym[i].stshndx) { case SHNCOMMON:

[...]

default: / Divert to percpu allocation if a percpu var. / if (sym[i].stshndx == info->index.pcpu) secbase = (unsigned long)modpercpu(mod); else / HERE --> / secbase = info->sechdrs[sym[i].stshndx].shaddr; sym[i].stvalue += secbase; break; } }

A symbol with an out-of-bounds stshndx value, for example 0xffff (known as SHNXINDEX or SHNHIRESERVE), may cause a kernel panic:

BUG: unable to handle page fault for address: ... RIP: 0010:simplifysymbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exception

This can happen when module ELF is legitimately using SHNXINDEX or when it is corrupted.

Add a bounds check in simplifysymbols() to validate that stshndx is within the valid range before using it.

This issue was discovered due to a bug in llvm-objcopy, see relevant discussion for details [1].

[1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/

btrfs: set BTRFSROOTORPHANCLEANUP during subvol create

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

xfrm: prevent policyhthresh.work from racing with netns teardown

A XFRMMSGNEWSPDINFO request can queue the per-net work item policyhthresh.work onto the system workqueue.

The queued callback, xfrmhashrebuild(), retrieves the enclosing struct net via containerof(). If the net namespace is torn down before that work runs, the associated struct net may already have been freed, and xfrmhashrebuild() may then dereference stale memory.

xfrmpolicyfini() already flushes policyhashwork during teardown, but it does not synchronize policyhthresh.work.

Synchronize policyhthresh.work in xfrmpolicyfini() as well, so the queued work cannot outlive the net namespace teardown and access a freed struct net.

esp: fix skb leak with espintcp and async crypto

afkey: validate families in pfkeysendmigrate()

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

spi: use generic driveroverride 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 driveroverride infrastructure taking care of proper locking internally.

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

Also note that we do not enable the driveroverride feature of struct bustype, as SPI - in contrast to most other buses - passes "" to sysfsemit() when the driveroverride pointer is NULL. Thus, printing "\n" instead of "(null)\n".

Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2capecreddatarcv()

Bluetooth: L2CAP: Fix null-ptr-deref on l2capsockreadycb

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

net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devices

Maximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kb and 64 Kb respectively. Adjust max size definitions and return correct EEPROM length based on device. Also prevent out-of-bound read/write.

drm/msm: Fix another leak in the submit error path

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

spi: meson-spicc: Fix double-put in remove path

mesonspiccprobe() registers the controller with devmspiregistercontroller(), so teardown already drops the controller reference via devm cleanup.

Calling spicontrollerput() again in mesonspiccremove() causes a double-put.

fbdev: Fix doregisterframebuffer to prevent null-ptr-deref in fbvideomodetovar

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

net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query

Fix a "scheduling while atomic" bug in mlx5eipsecinitmacs() by replacing mlx5querymacaddress() with etheraddrcopy() to get the local MAC address directly from netdev->devaddr.

The issue occurs because mlx5querymacaddress() queries the hardware which involves mlx5cmdexec() that can sleep, but it is called from the mlx5eipsechandleevent workqueue which runs in atomic context.

The MAC address is already available in netdev->devaddr, so no need to query hardware. This avoids the sleeping call and resolves the bug.

Call trace: BUG: scheduling while atomic: kworker/u112:2/69344/0x00000200 schedule+0x7ab/0xa20 schedule+0x1c/0xb0 scheduletimeout+0x6e/0xf0 waitforcommon+0x91/0x1b0 cmdexec+0xa85/0xff0 [mlx5core] mlx5cmdexec+0x1f/0x50 [mlx5core] mlx5querynicvportmacaddress+0x7b/0xd0 [mlx5core] mlx5querymacaddress+0x19/0x30 [mlx5core] mlx5eipsecinitmacs+0xc1/0x720 [mlx5core] mlx5eipsecbuildaccelxfrmattrs+0x422/0x670 [mlx5core] mlx5eipsechandleevent+0x2b9/0x460 [mlx5core] processonework+0x178/0x2e0 workerthread+0x2ea/0x430