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

liveupdate: luofile: remember retrieve() status

LUO keeps track of successful retrieve attempts on a LUO file. It does so to avoid multiple retrievals of the same file. Multiple retrievals cause problems because once the file is retrieved, the serialized data structures are likely freed and the file is likely in a very different state from what the code expects.

The retrieve boolean in struct luofile keeps track of this, and is passed to the finish callback so it knows what work was already done and what it has left to do.

All this works well when retrieve succeeds. When it fails, luoretrievefile() returns the error immediately, without ever storing anywhere that a retrieve was attempted or what its error code was. This results in an errored LIVEUPDATESESSIONRETRIEVEFD ioctl to userspace, but nothing prevents it from trying this again.

The retry is problematic for much of the same reasons listed above. The file is likely in a very different state than what the retrieve logic normally expects, and it might even have freed some serialization data structures. Attempting to access them or free them again is going to break things.

For example, if memfd managed to restore 8 of its 10 folios, but fails on the 9th, a subsequent retrieve attempt will try to call khorestorefolio() on the first folio again, and that will fail with a warning since it is an invalid operation.

Apart from the retry, finish() also breaks. Since on failure the retrieved bool in luofile is never touched, the finish() call on session close will tell the file handler that retrieve was never attempted, and it will try to access or free the data structures that might not exist, much in the same way as the retry attempt.

There is no sane way of attempting the retrieve again. Remember the error retrieve returned and directly return it on a retry. Also pass this status code to finish() so it can make the right decision on the work it needs to do.

This is done by changing the bool to an integer. A value of 0 means retrieve was never attempted, a positive value means it succeeded, and a negative value means it failed and the error code is the value.

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 xhciirq() 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 xhcihalt().

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.

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

arm64: contpte: fix setaccessflags() no-op check for SMMU/ATS faults

contpteptepsetaccessflags() compared the gathered ptepget() value against the requested entry to detect no-ops. ptepget() ORs AF/dirty from all sub-PTEs in the CONT block, so a dirty sibling can make the target appear already-dirty. When the gathered value matches entry, the function returns 0 even though the target sub-PTE still has PTERDONLY set in hardware.

For a CPU with FEATHAFDBS this gathered view is fine, since hardware may set AF/dirty on any sub-PTE and CPU TLB behavior is effectively gathered across the CONT range. But page-table walkers that evaluate each descriptor individually (e.g. a CPU without DBM support, or an SMMU without HTTU, or with HA/HD disabled in CD.TCR) can keep faulting on the unchanged target sub-PTE, causing an infinite fault loop.

Gathering can therefore cause false no-ops when only a sibling has been updated: - write faults: target still has PTERDONLY (needs PTERDONLY cleared) - read faults: target still lacks PTEAF

Fix by checking each sub-PTE against the requested AF/dirty/write state (the same bits consumed by ptepsetaccessflags()), using raw per-PTE values rather than the gathered ptepget() view, before returning no-op. Keep using the raw target PTE for the write-bit unfold decision.

Per Arm ARM (DDI 0487) D8.7.1 ("The Contiguous bit"), any sub-PTE in a CONT range may become the effective cached translation and software must maintain consistent attributes across the range.

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

ata: libata-core: Disable LPM on ST1000DM010-2EP102

According to a user report, the ST1000DM010-2EP102 has problems with LPM, causing random system freezes. The drive belongs to the same BarraCuda family as the ST2000DM008-2FR102 which has the same issue.

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

nouveau/gsp: drop WARNON in ACPI probes

These WARNONs seem to trigger a lot, and we don't seem to have a plan to fix them, so just drop them, as they are most likely harmless.

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

mmc: core: Avoid bitfield RMW for claim/retune flags

Move claimed and retune control flags out of the bitfield word to avoid unrelated RMW side effects in asynchronous contexts.

The host->claimed bit shared a word with retune flags. Writes to claimed in mmcclaimhost() or retunenow in mmcmqqueuerq() can overwrite other bits when concurrent updates happen in other contexts, triggering spurious WARNON(!host->claimed). Convert claimed, canretune, retunenow and retunepaused to bool to remove shared-word coupling.

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::VTPR 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 updatecr8intercept(), 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:

schedext: Disable preemption between scxclaimexit() and kicking helper work

scxclaimexit() atomically sets exitkind, which prevents scxerror() from triggering further error handling. After claiming exit, the caller must kick the helper kthread work which initiates bypass mode and teardown.

If the calling task gets preempted between claiming exit and kicking the helper work, and the BPF scheduler fails to schedule it back (since error handling is now disabled), the helper work is never queued, bypass mode never activates, tasks stop being dispatched, and the system wedges.

Disable preemption across scxclaimexit() and the subsequent work kicking in all callers - scxdisable() and scxvexit(). Add lockdepassertpreemptiondisabled() to scxclaimexit() to enforce the requirement.

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

ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisition

The acp3x5682init() function did not check the return value of clkget(), which could lead to dereferencing error pointers in rt5682clkenable().

Fix this by: 1. Changing clkget() to the device-managed devmclkget(). 2. Adding proper ISERR() checks for both clock acquisitions.

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

ASoC: codecs: rt1011: Use component to get the dapm context in spkmodeput

The correct helper to use in rt1011recvspkmodeput() to retrieve the DAPM context is sndsoccomponenttodapm(), from kcontrol we will receive NULL pointer.

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

net: usb: lan78xx: fix WARN in netifnapidellocked on disconnect

Remove redundant netifnapidel() call from disconnect path.

A WARN may be triggered in netifnapidellocked() during USB device disconnect:

WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 netifnapidellocked+0x2b4/0x350

This happens because netifnapidel() is called in the disconnect path while NAPI is still enabled. However, it is not necessary to call netifnapidel() explicitly, since unregisternetdev() will handle NAPI teardown automatically and safely. Removing the redundant call avoids triggering the warning.

Full trace: lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV lan78xx 1-1:1.0 enu1: Link is Down lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 netifnapidellocked+0x2b4/0x350 Modules linked in: flexcan candev fuse CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT Hardware name: SKOV IMX8MP CPU revC - bd500 (DT) Workqueue: usbhubwq hubevent pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : netifnapidellocked+0x2b4/0x350 lr : netifnapidellocked+0x7c/0x350 sp : ffffffc085b673c0 x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8 x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000 x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000 x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028 x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8 x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000 x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001 x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000 Call trace: netifnapidellocked+0x2b4/0x350 (P) lan78xxdisconnect+0xf4/0x360 usbunbindinterface+0x158/0x718 deviceremove+0x100/0x150 devicereleasedriverinternal+0x308/0x478 devicereleasedriver+0x1c/0x30 busremovedevice+0x1a8/0x368 devicedel+0x2e0/0x7b0 usbdisabledevice+0x244/0x540 usbdisconnect+0x220/0x758 hubevent+0x105c/0x35e0 processonework+0x760/0x17b0 workerthread+0x768/0xce8 kthread+0x3bc/0x690 retfromfork+0x10/0x20 irq event stamp: 211604 hardirqs last enabled at (211603): [<ffffffc0828cc9ec>] rawspinunlockirqrestore+0x84/0x98 hardirqs last disabled at (211604): [<ffffffc0828a9a84>] el1dbg+0x24/0x80 softirqs last enabled at (211296): [<ffffffc080095f10>] handlesoftirqs+0x820/0xbc8 softirqs last disabled at (210993): [<ffffffc080010288>] dosoftirq+0x18/0x20 ---[ end trace 0000000000000000 ]--- lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0

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

drm/i915/vrr: Configure VRR timings after enabling TRANSDDIFUNCCTL

Apparently ICL may hang with an MCE if we write TRANSVRRVMAX/FLIPLINE before enabling TRANSDDIFUNCCTL.

Personally I was only able to reproduce a hang (on an Dell XPS 7390 2-in-1) with an external display connected via a dock using a dodgy type-C cable that made the link training fail. After the failed link training the machine would hang. TGL seemed immune to the problem for whatever reason.

BSpec does tell us to configure VRR after enabling TRANSDDIFUNCCTL as well. The DMC firmware also does the VRR restore in two stages: - first stage seems to be unconditional and includes TRANSVRRCTL and a few other VRR registers, among other things - second stage is conditional on the DDI being enabled, and includes TRANSDDIFUNCCTL and TRANSVRRVMAX/VMIN/FLIPLINE, among other things

So let's reorder the steps to match to avoid the hang, and toss in an extra WARN to make sure we don't screw this up later.

BSpec: 22243 (cherry picked from commit 93f3a267c3dd4d811b224bb9e179a10d81456a74)

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

scsi: storvsc: Fix scheduling while atomic on PREEMPTRT

This resolves the follow splat and lock-up when running with PREEMPTRT enabled on Hyper-V:

[ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002 [ 415.140822] INFO: lockdep is turned off. [ 415.140823] Modules linked in: intelraplmsr intelraplcommon inteluncorefrequencycommon intelpmccore pmttelemetry pmtdiscovery pmtclass intelpmcssramtelemetry intelvsec ghashclmulniintel aesniintel rapl binfmtmisc nlsascii nlscp437 vfat fat sndpcm hypervdrm sndtimer drmclientlib drmshmemhelper snd sg soundcore drmkmshelper pcspkr hvballoon hvutils evdev joydev drm configfs efipstore nfnetlink vsockloopback vmwvsockvirtiotransportcommon hvsock vmwvsockvmcitransport vsock vmwvmci efivarfs autofs4 ext4 crc16 mbcache jbd2 srmod sdmod cdrom hvstorvsc serioraw hidgeneric scsitransportfc hidhyperv scsimod hid hvnetvsc hypervkeyboard scsicommon [ 415.140846] Preemption disabled at: [ 415.140847] [<ffffffffc0656171>] storvscqueuecommand+0x2e1/0xbe0 [hvstorvsc] [ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT{RT,(full)} [ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024 [ 415.140857] Call Trace: [ 415.140861] <TASK> [ 415.140861] ? storvscqueuecommand+0x2e1/0xbe0 [hvstorvsc] [ 415.140863] dumpstacklvl+0x91/0xb0 [ 415.140870] schedulebug+0x9c/0xc0 [ 415.140875] schedule+0xdf6/0x1300 [ 415.140877] ? rtlockslowlocklocked+0x56c/0x1980 [ 415.140879] ? rcuiswatching+0x12/0x60 [ 415.140883] schedulertlock+0x21/0x40 [ 415.140885] rtlockslowlocklocked+0x502/0x1980 [ 415.140891] rtspinlock+0x89/0x1e0 [ 415.140893] hvringbufferwrite+0x87/0x2a0 [ 415.140899] vmbussendpacketmpbdesc+0xb6/0xe0 [ 415.140900] ? rcuiswatching+0x12/0x60 [ 415.140902] storvscqueuecommand+0x669/0xbe0 [hvstorvsc] [ 415.140904] ? HARDIRQverbose+0x10/0x10 [ 415.140908] ? rqqosissue+0x28/0x40 [ 415.140911] scsiqueuerq+0x760/0xd80 [scsimod] [ 415.140926] blkmqissuedirectly+0x4a/0xc0 [ 415.140928] blkmqissuedirect+0x87/0x2b0 [ 415.140931] blkmqdispatchqueuerequests+0x120/0x440 [ 415.140933] blkmqflushpluglist+0x7a/0x1a0 [ 415.140935] blkflushplug+0xf4/0x150 [ 415.140940] submitbio+0x2b2/0x5c0 [ 415.140944] ? submitbionoacctnocheck+0x272/0x360 [ 415.140946] submitbionoacctnocheck+0x272/0x360 [ 415.140951] ext4readbhlock+0x3e/0x60 [ext4] [ 415.140995] ext4blockwritebegin+0x396/0x650 [ext4] [ 415.141018] ? pfxext4dagetblockprep+0x10/0x10 [ext4] [ 415.141038] ext4dawritebegin+0x1c4/0x350 [ext4] [ 415.141060] genericperformwrite+0x14e/0x2c0 [ 415.141065] ext4bufferedwriteiter+0x6b/0x120 [ext4] [ 415.141083] vfswrite+0x2ca/0x570 [ 415.141087] ksyswrite+0x76/0xf0 [ 415.141089] dosyscall64+0x99/0x1490 [ 415.141093] ? rcuiswatching+0x12/0x60 [ 415.141095] ? finishtaskswitch.isra.0+0xdf/0x3d0 [ 415.141097] ? rcuiswatching+0x12/0x60 [ 415.141098] ? lockrelease+0x1f0/0x2a0 [ 415.141100] ? rcuiswatching+0x12/0x60 [ 415.141101] ? finishtaskswitch.isra.0+0xe4/0x3d0 [ 415.141103] ? rcuiswatching+0x12/0x60 [ 415.141104] ? schedule+0xb34/0x1300 [ 415.141106] ? hrtimertrytocancel+0x1d/0x170 [ 415.141109] ? donanosleep+0x8b/0x160 [ 415.141111] ? hrtimernanosleep+0x89/0x100 [ 415.141114] ? pfxhrtimerwakeup+0x10/0x10 [ 415.141116] ? xfdvalidatestate+0x26/0x90 [ 415.141118] ? rcuiswatching+0x12/0x60 [ 415.141120] ? dosyscall64+0x1e0/0x1490 [ 415.141121] ? dosyscall64+0x1e0/0x1490 [ 415.141123] ? rcuiswatching+0x12/0x60 [ 415.141124] ? dosyscall64+0x1e0/0x1490 [ 415.141125] ? dosyscall64+0x1e0/0x1490 [ 415.141127] ? irqentryexit+0x140/0 ---truncated---

fs: init flagsvalid before calling vfsfileattrget

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

scsi: mpi3mr: Add NULL checks when resetting request and reply queues

The driver encountered a crash during resource cleanup when the reply and request queues were NULL due to freed memory. This issue occurred when the creation of reply or request queues failed, and the driver freed the memory first, but attempted to mem set the content of the freed memory, leading to a system crash.

Add NULL pointer checks for reply and request queues before accessing the reply/request memory during cleanup

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

unshare: fix unsharefs() 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 copymntns() 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) ;-/

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

scsi: ufs: core: Fix possible NULL pointer dereference in ufshcdaddcommandtrace()

The kernel log indicates a crash in ufshcdaddcommandtrace, due to a NULL pointer dereference when accessing hwq->id. This can happen if ufshcdmcqreqtohwq() returns NULL.

This patch adds a NULL check for hwq before accessing its id field to prevent a kernel crash.

Kernel log excerpt: [<ffffffd5d192dc4c>] notifydie+0x4c/0x8c [<ffffffd5d1814e58>] die+0x60/0xb0 [<ffffffd5d1814d64>] die+0x4c/0xe0 [<ffffffd5d181575c>] diekernelfault+0x74/0x88 [<ffffffd5d1864db4>] dokernelfault+0x314/0x318 [<ffffffd5d2a3cdf8>] dopagefault+0xa4/0x5f8 [<ffffffd5d2a3cd34>] dotranslationfault+0x34/0x54 [<ffffffd5d1864524>] domemabort+0x50/0xa8 [<ffffffd5d2a297dc>] el1abort+0x3c/0x64 [<ffffffd5d2a29718>] el1h64synchandler+0x44/0xcc [<ffffffd5d181133c>] el1h64sync+0x80/0x88 [<ffffffd5d255c1dc>] ufshcdaddcommandtrace+0x23c/0x320 [<ffffffd5d255bad8>] ufshcdcomplonecqe+0xa4/0x404 [<ffffffd5d2572968>] ufshcdmcqpollcqelock+0xac/0x104 [<ffffffd5d11c7460>] ufsmtkmcqintr+0x54/0x74 [ufsmediatekmod] [<ffffffd5d19ab92c>] handleirqeventpercpu+0xc8/0x348 [<ffffffd5d19abca8>] handleirqevent+0x3c/0xa8 [<ffffffd5d19b1f0c>] handlefasteoiirq+0xf8/0x294 [<ffffffd5d19aa778>] generichandledomainirq+0x54/0x80 [<ffffffd5d18102bc>] gichandleirq+0x1d4/0x330 [<ffffffd5d1838210>] callonirqstack+0x44/0x68 [<ffffffd5d183af30>] dointerrupthandler+0x78/0xd8 [<ffffffd5d2a29c00>] el1interrupt+0x48/0xa8 [<ffffffd5d2a29ba8>] el1h64irqhandler+0x14/0x24 [<ffffffd5d18113c4>] el1h64irq+0x80/0x88 [<ffffffd5d2527fb4>] archlocalirqenable+0x4/0x1c [<ffffffd5d25282e4>] cpuidleenter+0x34/0x54 [<ffffffd5d195a678>] doidle+0x1dc/0x2f8 [<ffffffd5d195a7c4>] cpustartupentry+0x30/0x3c [<ffffffd5d18155c4>] secondarystartkernel+0x134/0x1ac [<ffffffd5d18640bc>] secondaryswitched+0xc4/0xcc

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

nfs: return EISDIR on nfs3proccreate if dalias is a dir

If we found an alias through nfs3docreate/nfsaddorobtain /dsplicealias 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 OEXCL 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 finishopen) on a directory inode, which triggers the observed oops.

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

net/mlx5: Fix deadlock between devlink lock and esw->wq

esw->workqueue executes eswfunctionschangedeventhandler -> eswvfschangedeventhandler and acquires the devlink lock.

.eswitchmodeset (acquires devlink lock in devlinknlpredoit) -> mlx5devlinkeswitchmodeset -> mlx5eswitchdisablelocked -> mlx5eswitcheventhandlerunregister -> flushworkqueue deadlocks when eswvfschangedeventhandler executes.

Fix that by no longer flushing the work to avoid the deadlock, and using a generation counter to keep track of work relevance. This avoids an old handler manipulating an esw that has undergone one or more mode changes: - the counter is incremented in mlx5eswitcheventhandlerunregister. - the counter is read and passed to the ephemeral mlx5hostwork struct. - the work handler takes the devlink lock and bails out if the current generation is different than the one it was scheduled to operate on. - mlx5eswitchcleanup does the final draining before destroying the wq.

No longer flushing the workqueue has the side effect of maybe no longer cancelling pending vportchangehandler work items, but that's ok since those are disabled elsewhere: - mlx5eswitchdisablelocked disables the vport eq notifier. - mlx5eswvportdisable disarms the HW EQ notification and marks vport->enabled under statelock to false to prevent pending vport handler from doing anything. - mlx5eswitchcleanup destroys the workqueue and makes sure all events are disabled/finished.

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

net/mlx5: Fix crash when moving to switchdev mode

When moving to switchdev mode when the device doesn't support IPsec, we try to clean up the IPsec resources anyway which causes the crash below, fix that by correctly checking for IPsec support before trying to clean up its resources.

[27642.515799] WARNING: arch/x86/mm/fault.c:1276 at douseraddrfault+0x18a/0x680, CPU#4: devlink/6490 [27642.517159] Modules linked in: xtconntrack xtMASQUERADE ip6tablenat ip6tablefilter ip6tables iptablenat nfnat xtaddrtype rpcsecgsskrb5 authrpcgss oidregistry overlay mlx5fwctl nfnetlink zram zsmalloc mlx5ib fuse rpcrdma rdmaucm ibuverbs ibiser libiscsi scsitransportiscsi ibumad rdmacm ibipoib iwcm ibcm mlx5core ibcore [27642.521358] CPU: 4 UID: 0 PID: 6490 Comm: devlink Not tainted 6.19.0-rc5forupstreammindebug202601141647 #1 NONE [27642.522923] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [27642.524528] RIP: 0010:douseraddrfault+0x18a/0x680 [27642.525362] Code: ff 0f 84 75 03 00 00 48 89 ee 4c 89 e7 e8 5e b9 22 00 49 89 c0 48 85 c0 0f 84 a8 02 00 00 f7 c3 60 80 00 00 74 22 31 c9 eb ae <0f> 0b 48 83 c4 10 48 89 ea 48 89 de 4c 89 f7 5b 5d 41 5c 41 5d 41 [27642.528166] RSP: 0018:ffff88810770f6b8 EFLAGS: 00010046 [27642.529038] RAX: 0000000000000000 RBX: 0000000000000002 RCX: ffff88810b980f00 [27642.530158] RDX: 00000000000000a0 RSI: 0000000000000002 RDI: ffff88810770f728 [27642.531270] RBP: 00000000000000a0 R08: 0000000000000000 R09: 0000000000000000 [27642.532383] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888103f3c4c0 [27642.533499] R13: 0000000000000000 R14: ffff88810770f728 R15: 0000000000000000 [27642.534614] FS: 00007f197c741740(0000) GS:ffff88856a94c000(0000) knlGS:0000000000000000 [27642.535915] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [27642.536858] CR2: 00000000000000a0 CR3: 000000011334c003 CR4: 0000000000172eb0 [27642.537982] Call Trace: [27642.538466] <TASK> [27642.538907] excpagefault+0x76/0x140 [27642.539583] asmexcpagefault+0x22/0x30 [27642.540282] RIP: 0010:rawspinlockirqsave+0x10/0x30 [27642.541134] Code: 07 85 c0 75 11 ba ff 00 00 00 f0 0f b1 17 75 06 b8 01 00 00 00 c3 31 c0 c3 90 0f 1f 44 00 00 53 9c 5b fa 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 05 48 89 d8 5b c3 89 c6 e8 7e 02 00 00 48 89 d8 5b [27642.543936] RSP: 0018:ffff88810770f7d8 EFLAGS: 00010046 [27642.544803] RAX: 0000000000000000 RBX: 0000000000000202 RCX: ffff888113ad96d8 [27642.545916] RDX: 0000000000000001 RSI: ffff88810770f818 RDI: 00000000000000a0 [27642.547027] RBP: 0000000000000098 R08: 0000000000000400 R09: ffff88810b980f00 [27642.548140] R10: 0000000000000001 R11: ffff888101845a80 R12: 00000000000000a8 [27642.549263] R13: ffffffffa02a9060 R14: 00000000000000a0 R15: ffff8881130d8a40 [27642.550379] completeall+0x20/0x90 [27642.551010] mlx5eipsecdisableevents+0xb6/0xf0 [mlx5core] [27642.552022] mlx5enicdisable+0x12d/0x220 [mlx5core] [27642.552929] mlx5edetachnetdev+0x66/0xf0 [mlx5core] [27642.553822] mlx5enetdevchangeprofile+0x5b/0x120 [mlx5core] [27642.554821] mlx5evportrepload+0x419/0x590 [mlx5core] [27642.555757] ? xaload+0x53/0x90 [27642.556361] eswoffloadsloadrep+0x54/0x70 [mlx5core] [27642.557328] mlx5eswoffloadsrepload+0x45/0xd0 [mlx5core] [27642.558320] eswoffloadsenable+0xb4b/0xc90 [mlx5core] [27642.559247] mlx5eswitchenablelocked+0x34e/0x4f0 [mlx5core] [27642.560257] ? mlx5rescandriverslocked+0x222/0x2d0 [mlx5core] [27642.561284] mlx5devlinkeswitchmodeset+0x5ac/0x9c0 [mlx5core] [27642.562334] ? devlinkratesetopssupported+0x21/0x3a0 [27642.563220] devlinknleswitchsetdoit+0x67/0xe0 [27642.564026] genlfamilyrcvmsgdoit+0xe0/0x130 [27642.564816] genlrcvmsg+0x183/0x290 [27642.565466] ? devlinknlpredoit.isra.0+0x160/0x160 [27642.566329] ? d ---truncated---

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

rxrpc, afs: Fix missing error pointer check after rxrpckernellookuppeer()

rxrpckernellookuppeer() can also return error pointers in addition to NULL, so just checking for NULL is not sufficient.

Fix this by:

(1) Changing rxrpckernellookuppeer() to return -ENOMEM rather than NULL on allocation failure.

(2) Making the callers in afs use ISERR() and PTRERR() to pass on the error code returned.

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

mctp: i2c: fix skb memory leak in receive path

When 'midev->allowrx' is false, the newly allocated skb isn't consumed by netifrx(), it needs to free the skb directly.

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

mctp: route: hold key->lock in mctpflowprepareoutput()

mctpflowprepareoutput() checks key->dev and may call mctpdevsetkey(), but it does not hold key->lock while doing so.

mctpdevsetkey() and mctpdevreleasekey() are annotated with musthold(&key->lock), so key->dev access is intended to be serialized by key->lock. The mctpsendmsg() transmit path reaches mctpflowprepareoutput() via mctplocaloutput() -> mctpdstoutput() without holding key->lock, so the check-and-set sequence is racy.

Example interleaving:

CPU0 CPU1 ---- ---- mctpflowprepareoutput(key, devA) if (!key->dev) // sees NULL mctpflowprepareoutput( key, devB) if (!key->dev) // still NULL mctpdevsetkey(devB, key) mctpdevhold(devB) key->dev = devB mctpdevsetkey(devA, key) mctpdevhold(devA) key->dev = devA // overwrites devB

Now both devA and devB references were acquired, but only the final key->dev value is tracked for release. One reference can be lost, causing a resource leak as mctpdevreleasekey() would only decrease the reference on one dev.

Fix by taking key->lock around the key->dev check and mctpdevsetkey() call.

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

netfilter: nfnetlinkqueue: fix entry leak in bridge verdict error path

nfqnlrecvverdict() calls finddequeueentry() to remove the queue entry from the queue data structures, taking ownership of the entry. For PFBRIDGE packets, it then calls nfqaparsebridge() to parse VLAN attributes. If nfqaparsebridge() returns an error (e.g. NFQAVLAN present but NFQAVLANTCI missing), the function returns immediately without freeing the dequeued entry or its skbuff.

This leaks the nfqueueentry, its associated skbuff, and all held references (netdevice refcounts, struct net refcount). Repeated triggering exhausts kernel memory.

Fix this by dropping the entry via nfqnlreinject() with NFDROP verdict on the error path, consistent with other error handling in this file.

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

nvme-pci: Fix race bug in nvmepollirqdisable()

In the following scenario, pdev can be disabled between (1) and (3) by (2). This sets pdev->msixenabled = 0. Then, pciirqvector() will return MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2). This causes IRQ warning because it tries to enable INTx IRQ that has never been disabled before.

To fix this, save IRQ number into a local variable and ensure disableirq() and enableirq() operate on the same IRQ number. Even if pcifreeirqvectors() frees the IRQ concurrently, disableirq() and enableirq() on a stale IRQ number is still valid and safe, and the depth accounting reamins balanced.

task 1: nvmepollirqdisable() disableirq(pciirqvector(pdev, nvmeq->cqvector)) ...(1) enableirq(pciirqvector(pdev, nvmeq->cqvector)) ...(3)

task 2: nvmeresetwork() nvmedevdisable() pdev->msixenable = 0; ...(2)

crash log:

------------[ cut here ]------------ Unbalanced enable for IRQ 10 WARNING: kernel/irq/manage.c:753 at enableirq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26 Modules linked in: CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blkmqtimeoutwork RIP: 0010:enableirq+0x107/0x190 kernel/irq/manage.c:753 Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9 RSP: 0018:ffffc900001bf550 EFLAGS: 00010046 RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90 RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0 RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001 R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000 R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293 FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0 Call Trace: <TASK> enableirq+0x121/0x1e0 kernel/irq/manage.c:797 nvmepollirqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494 nvmetimeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744 blkmqrqtimedout block/blk-mq.c:1653 [inline] blkmqhandleexpired+0x227/0x2d0 block/blk-mq.c:1721 btiter+0x2fc/0x3a0 block/blk-mq-tag.c:292 sbitmapforeachset include/linux/sbitmap.h:269 [inline] sbitmapforeachset include/linux/sbitmap.h:290 [inline] btforeach block/blk-mq-tag.c:324 [inline] blkmqqueuetagbusyiter+0x969/0x1e80 block/blk-mq-tag.c:536 blkmqtimeoutwork+0x627/0x870 block/blk-mq.c:1763 processonework+0x956/0x1aa0 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 retfromfork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246 </TASK> irq event stamp: 74478 hardirqs last enabled at (74477): [<ffffffffb5720a9c>] rawspinunlockirq include/linux/spinlockapismp.h:159 [inline] hardirqs last enabled at (74477): [<ffffffffb5720a9c>] rawspinunlockirq+0x2c/0x60 kernel/locking/spinlock.c:202 hardirqs last disabled at (74478): [<ffffffffb57207b5>] rawspinlockirqsave include/linux/spinlockapismp.h:108 [inline] hardirqs last disabled at (74478): [<ffffffffb57207b5>] rawspinlockirqsave+0x85/0xa0 kernel/locking/spinlock.c:162 softirqs last enabled at (74304): [<ffffffffb1e9466c>] dosoftirq kernel/softirq.c:656 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] invokesoftirq kernel/softirq.c:496 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] irqexitrcu+0xdc/0x120 ---truncated---

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

accel/amdxdna: Fix runtime suspend deadlock when there is pending job

The runtime suspend callback drains the running job workqueue before suspending the device. If a job is still executing and calls pmruntimeresumeandget(), it can deadlock with the runtime suspend path.

Fix this by moving pmruntimeresumeandget() from the job execution routine to the job submission routine, ensuring the device is resumed before the job is queued and avoiding the deadlock during runtime suspend.

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

e1000/e1000e: Fix leak in DMA error cleanup

If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb.

Because count is incremented after a successful mapping, it will always match the correct number of unmappings needed when dmaerror is reached. Decrementing count before the while loop in dmaerror causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping would leak.

In these commits, a faulty while condition caused an infinite loop in dmaerror: Commit 03b1320dfcee ("e1000e: remove use of skbdmamap from e1000e driver") Commit 602c0554d7b0 ("e1000: remove use of skbdmamap from e1000 driver")

Commit c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in txmap()") fixed the infinite loop, but introduced the off-by-one error.

This issue may still exist in the igbvf driver, but I did not address it in this patch.

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

ASoC: amd: acp-mach-common: Add missing error check for clock acquisition

The acpcardrt5682init() and acpcardrt5682sinit() functions did not check the return values of clkget(). This could lead to a kernel crash when the invalid pointers are later dereferenced by clock core functions.

Fix this by: 1. Changing clkget() to the device-managed devmclkget(). 2. Adding ISERR() checks immediately after each clock acquisition.

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

drm/amdkfd: Unreserve bo if queue update failed

Error handling path should unreserve bo then return failed.

(cherry picked from commit c24afed7de9ecce341825d8ab55a43a254348b33)

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

cgroup: fix race between task migration and iteration

When a task is migrated out of a cssset, cgroupmigrateaddtask() first moves it from cset->tasks to cset->mgtasks via:

listmovetail(&task->cglist, &cset->mgtasks);

If a csstaskiter currently has it->taskpos pointing to this task, csssetmovetask() calls csstaskiterskip() to keep the iterator valid. However, since the task has already been moved to ->mgtasks, the iterator is advanced relative to the mgtasks list instead of the original tasks list. As a result, remaining tasks on cset->tasks, as well as tasks queued on cset->mgtasks, can be skipped by iteration.

Fix this by calling csssetskiptaskiters() before unlinking task->cglist from cset->tasks. This advances all active iterators to the next task on cset->tasks, so iteration continues correctly even when a task is concurrently being migrated.

This race is hard to hit in practice without instrumentation, but it can be reproduced by artificially slowing down cgroupprocsshow(). For example, on an Android device a temporary /sys/kernel/cgroup/cgrouptest knob can be added to inject a delay into cgroupprocsshow(), and then:

1) Spawn three long-running tasks (PIDs 101, 102, 103). 2) Create a test cgroup and move the tasks into it. 3) Enable a large delay via /sys/kernel/cgroup/cgrouptest. 4) In one shell, read cgroup.procs from the test cgroup. 5) Within the delay window, in another shell migrate PID 102 by writing it to a different cgroup.procs file.

Under this setup, cgroup.procs can intermittently show only PID 101 while skipping PID 103. Once the migration completes, reading the file again shows all tasks as expected.

Note that this change does not allow removing the existing csssetskiptaskiters() call in csssetmovetask(). The new call in cgroupmigrateaddtask() only handles iterators that are racing with migration while the task is still on cset->tasks. Iterators may also start after the task has been moved to cset->mgtasks. If we dropped csssetskiptaskiters() from csssetmovetask(), such iterators could keep taskpos pointing to a migrating task, causing csstaskiteradvance() to malfunction on the destination cssset, up to and including crashes or infinite loops.

The race window between migration and iteration is very small, and csstaskiter is not on a hot path. In the worst case, when an iterator is positioned on the first thread of the migrating process, cgroupmigrateaddtask() may have to skip multiple tasks via csssetskiptaskiters(). However, this only happens when migration and iteration actually race, so the performance impact is negligible compared to the correctness fix provided here.