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

sched/mmcid: Prevent CID stalls due to concurrent forks

A newly forked task is accounted as MMCID user before the task is visible in the process' thread list and the global task list. This creates the following problem:

CPU1 CPU2 fork() schedmmcidfork(tnew1) tnew1->mm.mmcidusers++; tnew1->mmcid.cid = getcid() -> preemption fork() schedmmcidfork(tnew2) tnew2->mm.mmcidusers++; // Reaches the per CPU threshold mmcidfixuptaskstocpus() foreachother(current, p) ....

As tnew1 is not visible yet, this fails to fix up the already allocated CID of tnew1. As a consequence a subsequent schedule in might fail to acquire a (transitional) CID and the machine stalls.

Move the invocation of schedmmcidfork() after the new task becomes visible in the thread and the task list to prevent this.

This also makes it symmetrical vs. exit() where the task is removed as CID user before the task is removed from the thread and task lists.

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

ASoC: qcom: qdsp6: Fix q6apm remove ordering during ADSP stop and start

During ADSP stop and start, the kernel crashes due to the order in which ASoC components are removed.

On ADSP stop, the q6apm-audio .remove callback unloads topology and removes PCM runtimes during ASoC teardown. This deletes the RTDs that contain the q6apm DAI components before their removal pass runs, leaving those components still linked to the card and causing crashes on the next rebind.

Fix this by ensuring that all dependent (child) components are removed first, and the q6apm component is removed last.

[ 48.105720] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 [ 48.114763] Mem abort info: [ 48.117650] ESR = 0x0000000096000004 [ 48.121526] EC = 0x25: DABT (current EL), IL = 32 bits [ 48.127010] SET = 0, FnV = 0 [ 48.130172] EA = 0, S1PTW = 0 [ 48.133415] FSC = 0x04: level 0 translation fault [ 48.138446] Data abort info: [ 48.141422] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 48.147079] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 48.152354] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 48.157859] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001173cf000 [ 48.164517] [00000000000000d0] pgd=0000000000000000, p4d=0000000000000000 [ 48.171530] Internal error: Oops: 0000000096000004 [#1] SMP [ 48.177348] Modules linked in: q6prmclocks q6apmlpassdais q6apmdai sndq6dspcommon q6prm sndq6apm 8021q garp mrp stp llc sndsochdmicodec apr pdrinterface phyqcomedp fastrpc qcompdmapper rpmsgctrl qrtrsmd rpmsgchar qcompdrmsg qcomiris v4l2mem2mem videobuf2dmacontig ath11kpci msm ubwcconfig at24 ath11k videobuf2memops mac80211 ocmem videobuf2v4l2 libarc4 drmgpuvm mhi qrtr videodev drmexec sndsocsc8280xp gpusched videobuf2common nvmemqcomspmisdam sndsocqcomsdw drmdpauxbus qcomq6v5pas qcomspmitempalarm sndsocqcomcommon rtcpm8xxx qcompon drmdisplayhelper cec qcompilinfo qcomstats soundwirebus drmclientlib mc dispcc0sa8775p videoccsa8775p qcomq6v5 camccsa8775p sndsocdmic phyqcomsgmiieth sndsocmax98357a i2cqcomgeni sndsoccore dwmacqcomethqos llccqcom iccbwmon qcomsysmon sndcompress qcomrefgenregulator coresightstm stmmacplatform sndpcmdmaengine qcomcommon coresighttmc stmmac coresightreplicator qcomglinksmem coresightcti stmcore [ 48.177444] coresightfunnel sndpcm ufsqcom phyqcomqmpusb gpi phyqcomsnpsfemtov2 coresight phyqcomqmpufs qcomwdt gpuccsa8775p pcsxpcs mdtloader qcomice iccosml3 qmihelpers sndtimer snd soundcore displayconnector qcomrng nvmemrebootmode drmkmshelper phyqcomqmppcie sha256 cfg80211 rfkill socinfo fuse drm backlight ipv6 [ 48.301059] CPU: 2 UID: 0 PID: 293 Comm: kworker/u32:2 Not tainted 6.19.0-rc6-dirty #10 PREEMPT [ 48.310081] Hardware name: Qualcomm Technologies, Inc. Lemans EVK (DT) [ 48.316782] Workqueue: pdrnotifierwq pdrnotifierwork [pdrinterface] [ 48.323672] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 48.330825] pc : mutexlock+0xc/0x54 [ 48.334514] lr : socdapmshutdowndapm+0x44/0x174 [sndsoccore] [ 48.340794] sp : ffff800084ddb7b0 [ 48.344207] x29: ffff800084ddb7b0 x28: ffff00009cd9cf30 x27: ffff00009cd9cc00 [ 48.351544] x26: ffff000099610190 x25: ffffa31d2f19c810 x24: ffffa31d2f185098 [ 48.358869] x23: ffff800084ddb7f8 x22: 0000000000000000 x21: 00000000000000d0 [ 48.366198] x20: ffff00009ba6c338 x19: ffff00009ba6c338 x18: 00000000ffffffff [ 48.373528] x17: 000000040044ffff x16: ffffa31d4ae6dca8 x15: 072007740775076f [ 48.380853] x14: 0765076d07690774 x13: 00313a323a656369 x12: 767265733a637673 [ 48.388182] x11: 00000000000003f9 x10: ffffa31d4c7dea98 x9 : 0000000000000001 [ 48.395519] x8 : ffff00009a2aadc0 x7 : 0000000000000003 x6 : 0000000000000000 [ 48.402854] x5 : 0000000000000 ---truncated---

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

mm: Fix a hmmrangefault() livelock / starvation problem

If hmmrangefault() fails a foliotrylock() in doswappage, trying to acquire the lock of a device-private folio for migration, to ram, the function will spin until it succeeds grabbing the lock.

However, if the process holding the lock is depending on a work item to be completed, which is scheduled on the same CPU as the spinning hmmrangefault(), that work item might be starved and we end up in a livelock / starvation situation which is never resolved.

This can happen, for example if the process holding the device-private folio lock is stuck in migratedeviceunmap()->lruadddrainall() sinc lruadddrainall() requires a short work-item to be run on all online cpus to complete.

A prerequisite for this to happen is: a) Both zone device and system memory folios are considered in migratedeviceunmap(), so that there is a reason to call lruadddrainall() for a system memory folio while a folio lock is held on a zone device folio. b) The zone device folio has an initial mapcount > 1 which causes at least one migration PTE entry insertion to be deferred to trytomigrate(), which can happen after the call to lruadddrainall(). c) No or voluntary only preemption.

This all seems pretty unlikely to happen, but indeed is hit by the "xeexecsystemallocator" igt test.

Resolve this by waiting for the folio to be unlocked if the foliotrylock() fails in doswappage().

Rename migrationentrywaitonlocked() to softleafentrywaitunlock() and update its documentation to indicate the new use-case.

Future code improvements might consider moving the lruadddrainall() call in migratedeviceunmap() to be called after all pages have migration entries inserted. That would eliminate also b) above.

v2: - Instead of a condresched() in hmmrangefault(), eliminate the problem by waiting for the folio to be unlocked in doswappage() (Alistair Popple, Andrew Morton) v3: - Add a stub migrationentrywaitonlocked() for the !CONFIGMIGRATION case. (Kernel Test Robot) v4: - Rename migrateentrywaitonlocked() to softleafentrywaitonlocked() and update docs (Alistair Popple) v5: - Add a WARNONONCE() for the !CONFIGMIGRATION version of softleafentrywaitonlocked(). - Modify wording around function names in the commit message (Andrew Morton)

(cherry picked from commit a69d1ab971a624c6f112cea61536569d579c3215)

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

md raid: fix hang when stopping arrays with metadata through dm-raid

When using device-mapper's dm-raid target, stopping a RAID array can cause the system to hang under specific conditions.

This occurs when:

- A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices)

- The top-level RAID device is then removed

Removing the top-level device triggers a hang in the following sequence: the dm-raid destructor calls mdstop(), which tries to flush the write-intent bitmap by writing to the metadata sub-devices. However, these devices are already suspended, making them unable to complete the write-intent operations and causing an indefinite block.

Fix:

- Prevent bitmap flushing when mdstop() is called from dm-raid destructor context and avoid a quiescing/unquescing cycle which could also cause I/O

- Still allow write-intent bitmap flushing when called from dm-raid suspend context

This ensures that RAID array teardown can complete successfully even when the underlying devices are in a suspended state.

This second patch uses mdisrdwr() to distinguish between suspend and destructor paths as elaborated on above.

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

mailbox: Prevent out-of-bounds access in fwmboxindexxlate()

Although it is guided that #mbox-cells must be at least 1, there are many instances of #mbox-cells = <0>; in the device tree. If that is the case and the corresponding mailbox controller does not provide fwxlate and ofxlate function pointers, fwmboxindexxlate() will be used by default and out-of-bounds accesses could occur due to lack of bounds check in that function.

btrfs: don't BUG() on unexpected delayed ref type in runonedelayedref()

9p/xen: protect xen9pfsfrontfree against concurrent calls

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

HID: prodikeys: Check presence of pm->inputep82

Fake USB devices can send their own report descriptors for which the inputmapping() hook does not get called. In this case, pm->inputep82 stays NULL, which leads to a crash later.

This does not happen with the real device, but can be provoked by imposing as one.

In multiple locations, there is a possible memory corruption due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

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

xfrm: account XFRMAIFID in aevent size calculation

xfrmgetae() allocates the reply skb with xfrmaeventmsgsize(), then buildaevent() appends attributes including XFRMAIFID when x->ifid is set.

xfrmaeventmsgsize() does not include space for XFRMAIFID. For states with ifid, buildaevent() can fail with -EMSGSIZE and hit BUGON(err < 0) in xfrmgetae(), turning a malformed netlink interaction into a kernel panic.

Account XFRMAIFID in the size calculation unconditionally and replace the BUGON with normal error unwinding.

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

xfrm6: fix uninitialized saddr in xfrm6getsaddr()

xfrm6getsaddr() does not check the return value of ipv6devgetsaddr(). When ipv6devgetsaddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6getsaddr() still returns 0 (success).

This causes the caller xfrmtmplresolveone() to use the uninitialized address in xfrmstatefind(), triggering KMSAN warning:

===================================================== BUG: KMSAN: uninit-value in xfrmstatefind+0x2424/0xa940 xfrmstatefind+0x2424/0xa940 xfrmresolveandcreatebundle+0x906/0x5a20 xfrmlookupwithifid+0xcc0/0x3770 xfrmlookuproute+0x63/0x2b0 iprouteoutputflow+0x1ce/0x270 udpsendmsg+0x2ce1/0x3400 inetsendmsg+0x1ef/0x2a0 socksendmsg+0x278/0x3d0 syssendto+0x593/0x720 x64syssendto+0x130/0x200 x64syscall+0x332b/0x3e70 dosyscall64+0xd3/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f

Local variable tmp.i.i created at: xfrmresolveandcreatebundle+0x3e3/0x5a20 xfrmlookupwithifid+0xcc0/0x3770 =====================================================

Fix by checking the return value of ipv6devgetsaddr() and propagating the error.

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

ksmbd: Don't log keys in SMB3 signing and encryption key generation

When KSMBDDEBUGAUTH logging is enabled, generatesmb3signingkey() and generatesmb3encryptionkey() log the session, signing, encryption, and decryption key bytes. Remove the logs to avoid exposing credentials.

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

vhost: move vdpa group bound check to vhostvdpa

Remove duplication by consolidating these here. This reduces the posibility of a parent driver missing them.

While we're at it, fix a bug in vdpasim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write.

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

iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode

Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") relies on pcidevisdisconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system.

For example, if a VM fails to connect to the PCIe device, "virsh destroy" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd.

Call Trace: qisubmitsync qiflushdeviotlb intelpasidteardownentry deviceblocktranslation blockingdomainattachdev iommuattachdevice iommudevicesetdomain iommugroupsetdomaininternal iommudetachgroup vfioiommutype1detachgroup vfiogroupdetachcontainer vfiogroupfopsrelease fput

Although pcideviceispresent() is slower than pcidevisdisconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase.

Besides, devtlbinvalidationwithpasid() is called only in the paths below, which are far less frequent than memory map/unmap.

1. mm-struct release 2. {attach,release}dev 3. set/remove PASID 4. dirty-tracking setup

The gain in system stability far outweighs the negligible cost of using pcideviceispresent() instead of pcidevisdisconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions.

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

pstore: ramcore: fix incorrect success return when vmap() fails

In persistentramvmap(), vmap() may return NULL on failure.

If offset is non-zero, adding offsetinpage(start) causes the function to return a non-NULL pointer even though the mapping failed. persistentrambuffermap() therefore incorrectly returns success.

Subsequent access to prz->buffer may dereference an invalid address and cause crashes.

Add proper NULL checking for vmap() failures.

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

drm/ioc32: stop speculation on the drmcompatioctl path

The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling arrayindexnospec() on the index to the function pointer list.

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

usb: gadget: frndis: Fix netdevice lifecycle with devicemove

The netdevice is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the netdevice survives, resulting in dangling sysfs symlinks:

console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory

Use devicemove() to reparent the netdevice between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling devicemove(NULL) moves the netdevice to the virtual device tree before the gadget device is destroyed. On rebinding, devicemove() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering.

To maintain compatibility with legacy composite drivers (e.g., multi.c), the borrowednet flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.

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

wifi: rtw89: pci: validate sequence number of TX release report

Hardware rarely reports abnormal sequence number in TX release report, which will access out-of-bounds of wdring->pages array, causing NULL pointer dereference.

BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1085 Comm: irq/129-rtw89p Tainted: G S U 6.1.145-17510-g2f3369c91536 #1 (HASH:69e8 1) Call Trace: <IRQ> rtw89pcireleasetx+0x18f/0x300 [rtw89pci (HASH:4c83 2)] rtw89pcinapipoll+0xc2/0x190 [rtw89pci (HASH:4c83 2)] netrxaction+0xfc/0x460 net/core/dev.c:6578 net/core/dev.c:6645 net/core/dev.c:6759 handlesoftirqs+0xbe/0x290 kernel/softirq.c:601 ? rtw89pciinterruptthreadfn+0xc5/0x350 [rtw89pci (HASH:4c83 2)] localbhenableip+0xeb/0x120 kernel/softirq.c:499 kernel/softirq.c:423 </IRQ> <TASK> rtw89pciinterruptthreadfn+0xf8/0x350 [rtw89pci (HASH:4c83 2)] ? irqthread+0xa7/0x340 kernel/irq/manage.c:0 irqthread+0x177/0x340 kernel/irq/manage.c:1205 kernel/irq/manage.c:1314 ? thawkernelthreads+0xb0/0xb0 kernel/irq/manage.c:1202 ? irqforcedthreadfn+0x80/0x80 kernel/irq/manage.c:1220 kthread+0xea/0x110 kernel/kthread.c:376 ? synchronizeirq+0x1a0/0x1a0 kernel/irq/manage.c:1287 ? kthreadassociateblkcg+0x80/0x80 kernel/kthread.c:331 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:295 </TASK>

To prevent crash, validate rppinfo.seq before using.

bpf: Fix incorrect pruning due to atomic fetch precision tracking

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

openvswitch: defer tunnel netdevput to RCU release

ovsnetdevtunneldestroy() may run after NETDEVUNREGISTER already detached the device. Dropping the netdev reference in destroy can race with concurrent readers that still observe vport->dev.

Do not release vport->dev in ovsnetdevtunneldestroy(). Instead, let vportnetdevfree() drop the reference from the RCU callback, matching the non-tunnel destroy path and avoiding additional synchronization under RTNL.

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

gpio: omap: do not register driver in probe()

Commit 11a78b794496 ("ARM: OMAP: MPUIO wake updates") registers the omapmpuiodriver from omapmpuioinit(), which is called from omapgpioprobe().

However, it neither makes sense to register drivers from probe() callbacks of other drivers, nor does the driver core allow registering drivers with a device lock already being held.

The latter was revealed by commit dc23806a7c47 ("driver core: enforce devicelock for drivermatchdevice()") leading to a potential deadlock condition described in [1].

Additionally, the omapmpuiodriver is never unregistered from the driver core, even if the module is unloaded.

Hence, register the omapmpuiodriver from the module initcall and unregister it in moduleexit().

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

fbdev: vt8500lcdfb: fix missing dmafreecoherent()

fbi->fb.screenbuffer is allocated with dmaalloccoherent() but is not freed if the error path is reached.

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

rtnetlink: add missing netlinknscapable() check for peer netns

rtnlnewlink() lacks a CAPNETADMIN capability check on the peer network namespace when creating paired devices (veth, vxcan, netkit). This allows an unprivileged user with a user namespace to create interfaces in arbitrary network namespaces, including initnet.

Add a netlinknscapable() check for CAPNETADMIN in the peer namespace before allowing device creation to proceed.

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

driver core: platform: 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]

Bluetooth: btintel: serialize btintelhwerror() with hcireqsynclock

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

comedi: medaq: Fix potential overrun of firmware buffer

me2600xilinxdownload() loads the firmware that was requested by requestfirmware(). It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable filelength and reads the data stream contents of length filelength from offset 16 onwards. Although it checks that the supplied firmware is at least 16 bytes long, it does not check that it is long enough to contain the data stream.

Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return -EINVAL.

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

xfrm: Wait for RCU readers during policy netns exit

xfrmpolicyfini() frees the policybydst hash tables after flushing the policy work items and deleting all policies, but it does not wait for concurrent RCU readers to leave their read-side critical sections first.

The policybydst tables are published via rcuassignpointer() and are looked up through rcudereferencecheck(), so netns teardown must also wait for an RCU grace period before freeing the table memory.

Fix this by adding synchronizercu() before freeing the policy hash tables.

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

xfrmuser: fix info leak in buildmapping()

struct xfrmusersaid has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.

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/

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

spi: spi-fsl-lpspi: fix teardown order issue (UAF)

There is a teardown order issue in the driver. The SPI controller is registered using devmspiregistercontroller(), which delays unregistration of the SPI controller until after the fsllpspiremove() function returns.

As the fsllpspiremove() function synchronously tears down the DMA channels, a running SPI transfer triggers the following NULL pointer dereference due to use after free:

| fsllpspi 42550000.spi: I/O Error in DMA RX | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] | Call trace: | fsllpspidmatransfer+0x260/0x340 [spifsllpspi] | fsllpspitransferone+0x198/0x448 [spifsllpspi] | spitransferonemessage+0x49c/0x7c8 | spipumptransfermessage+0x120/0x420 | spisync+0x2c4/0x520 | spisync+0x34/0x60 | spidevmessage+0x20c/0x378 [spidev] | spidevioctl+0x398/0x750 [spidev] [...]

Switch from devmspiregistercontroller() to spiregistercontroller() in fsllpspiprobe() and add the corresponding spiunregistercontroller() in fsllpspiremove().