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:

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:

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:

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:

ALSA: usb-audio: Check endpoint numbers at parsing Scarlett2 mixer interfaces

The Scarlett2 mixer quirk in USB-audio driver may hit a NULL dereference when a malformed USB descriptor is passed, since it assumes the presence of an endpoint in the parsed interface in scarlett2findfcinterface(), as reported by fuzzer.

For avoiding the NULL dereference, just add the sanity check of bNumEndpoints and skip the invalid interface.

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

rustbinder: fix oneway spam detection

The spam detection logic in TreeRange was executed before the current request was inserted into the tree. So the new request was not being factored in the spam calculation. Fix this by moving the logic after the new range has been inserted.

Also, the detection logic for ArrayRange was missing altogether which meant large spamming transactions could get away without being detected. Fix this by implementing an equivalent lowonewayspace() in ArrayRange.

Note that I looked into centralizing this logic in RangeAllocator but iterating through 'state' and 'size' got a bit too complicated (for me) and I abandoned this effort.

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

usb: xhci: Fix memory leak in xhcidisableslot()

xhcialloccommand() allocates a command structure and, when the second argument is true, also allocates a completion structure. Currently, the error handling path in xhcidisableslot() only frees the command structure using kfree(), causing the completion structure to leak.

Use xhcifreecommand() instead of kfree(). xhcifreecommand() correctly frees both the command structure and the associated completion structure. Since the command structure is allocated with zero-initialization, command->inctx is NULL and will not be erroneously freed by xhcifreecommand().

This bug was found using an experimental static analysis tool we are developing. The tool is based on the LLVM framework and is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available, but we plan to open-source it after our research is published.

The bug was originally detected on v6.13-rc1 using our static analysis tool, and we have verified that the issue persists in the latest mainline kernel.

We performed build testing on x8664 with allyesconfig using GCC=11.4.0. Since triggering these error paths in xhcidisableslot() requires specific hardware conditions or abnormal state, we were unable to construct a test case to reliably trigger these specific error paths at runtime.

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

xhci: Fix NULL pointer dereference when reading portli debugfs files

Michal reported and debgged a NULL pointer dereference bug in the recently added portli debugfs files

Oops is caused when there are more port registers counted in xhci->maxports than ports reported by Supported Protocol capabilities. This is possible if maxports is more than maximum port number, or if there are gaps between ports of different speeds the 'Supported Protocol' capabilities.

In such cases port->rhub will be NULL so we can't reach xhci behind it. Add an explicit NULL check for this case, and print portli in hex without dereferencing port->rhub.

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

usb: yurex: fix race in probe

The bbu member of the descriptor must be set to the value standing for uninitialized values before the URB whose completion handler sets bbu is submitted. Otherwise there is a window during which probing can overwrite already retrieved data.

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

USB: core: Limit the length of unkillable synchronous timeouts

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

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

In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.

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

USB: usbtmc: Use usbbulkmsgkillable() with user-specified timeouts

The usbtmc driver accepts timeout values specified by the user in an ioctl command, and uses these timeouts for some usbbulkmsg() calls. Since the user can specify arbitrarily long timeouts and usbbulkmsg() uses unkillable waits, call usbbulkmsgkillable() instead to avoid the possibility of the user hanging a kernel thread indefinitely.

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

usb: image: mdc800: kill download URB on timeout

mdc800deviceread() submits downloadurb and waits for completion. If the timeout fires and the device has not responded, the function returns without killing the URB, leaving it active.

A subsequent read() resubmits the same URB while it is still in-flight, triggering the WARN in usbsubmiturb():

"URB submitted while active"

Check the return value of waiteventtimeout() and kill the URB if it indicates timeout, ensuring the URB is complete before its status is inspected or the URB is resubmitted.

Similar to - commit 372c93131998 ("USB: yurex: fix control-URB timeout handling") - commit b98d5000c505 ("media: rc: iguanair: handle timeouts")

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

usb: gadget: ftcm: Fix NULL pointer dereferences in nexus handling

The tpg->tpgnexus pointer in the USB Target driver is dynamically managed and tied to userspace configuration via ConfigFS. It can be NULL if the USB host sends requests before the nexus is fully established or immediately after it is dropped.

Currently, functions like botsubmitcommand() and the data transfer paths retrieve tvnexus = tpg->tpgnexus and immediately dereference tvnexus->tvnsesess without any validation. If a malicious or misconfigured USB host sends a BOT (Bulk-Only Transport) command during this race window, it triggers a NULL pointer dereference, leading to a kernel panic (local DoS).

This exposes an inconsistent API usage within the module, as peer functions like usbgsubmitcommand() and botsendbadresponse() correctly implement a NULL check for tvnexus before proceeding.

Fix this by bringing consistency to the nexus handling. Add the missing if (!tvnexus) checks to the vulnerable BOT command and request processing paths, aborting the command gracefully with an error instead of crashing the system.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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

usb: gadget: fncm: Fix netdevice lifecycle with devicemove

The network device outlived its parent gadget device during disconnection, resulting in dangling sysfs links and null pointer dereference problems.

A prior attempt to solve this by removing SETNETDEVDEV entirely [1] was reverted due to power management ordering concerns and a NO-CARRIER regression.

A subsequent attempt to defer netdevice allocation to bind [2] broke 1:1 mapping between function instance and network device, making it impossible for configfs to report the resolved interface name. This results in a regression where the DHCP server fails on pmOS.

Use devicemove to reparent the netdevice between the gadget device and /sys/devices/virtual/ across bind/unbind cycles. This preserves the network interface across USB reconnection, allowing the DHCP server to retain their binding.

Introduce getherattachgadget()/getherdetachgadget() helpers and use free(detachgadget) macro to undo attachment on bind failure. The bindcount ensures devicemove executes only on the first bind.

[1] https://lore.kernel.org/lkml/f2a4f9847617a0929d62025748384092e5f35cce.camel@crapouillou.net/ [2] https://lore.kernel.org/linux-usb/795ea759-7eaf-4f78-81f4-01ffbf2d7961@ixit.cz/