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

iommufd: Set upper bounds on cache invalidation entrynum and entrylen

iommufdhwptinvalidate() takes a user-controlled entrynum and entrylen, each bounded only by U32MAX. An entrylen beyond the kernel's struct size makes the copy helper verify the extra bytes are zero, scanning that excess in one uninterruptible pass; a multi-gigabyte value over zeroed user memory trips the soft-lockup watchdog.

A large entrynum is the other half, driving the backend invalidation loop with no reschedule. The VT-d nested handler, for one, copies each entry and flushes caches per iteration, pinning the CPU on a non-preemptible kernel.

Cap both in the ioctl. entrylen is held under PAGESIZE, above any request struct, and entrynum under 1 << 19, the order of a hardware invalidation queue and well beyond any real batch, bounding the per-call loop length.

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

xfs: don't wrap around quota ids in dqiterate

LOLLM noticed that qid is an unsigned 32-bit variable. If it happens to be set to XFSDQIDMAX due to a filesystem that actually has a dquot for IDMAX, then this addition will truncate to zero and the iteration starts over. Fix this by casting to u64.

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

mm/memoryhotplug: fix memory block reference leak on remove

Patch series "mm: Fix memory block leaks and locking", v2.

This series fixes two memory block device reference leaks and one locking issue around the per-memoryblock hwpoison counter.

This patch (of 2):

removememoryblocksandaltmaps() looks up each memory block with findmemoryblock(), which acquires a reference to the memory block device.

That reference is never dropped on this path, resulting in a leaked device reference when removing memory blocks and their altmaps. Drop the reference after retrieving mem->altmap and clearing mem->altmap, before removing the memory block device.

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

pdscore: fix debugfslookup dentry leak and error handling

debugfslookup() returns a dentry with an elevated reference count that must be released with dput(). The current code discards the returned dentry without calling dput(), causing a reference leak on every firmware reset recovery.

Additionally, when CONFIGDEBUGFS is disabled, debugfslookup() returns ERRPTR(-ENODEV), not NULL. The current check passes for error pointers and would call dput() on an invalid pointer, causing a crash.

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

tee: shm: fix shm leak in registershmhelper()

registershmhelper() allocates shm before calling ioviternpages(). If ioviternpages() returns 0, the function jumps to errctxput and leaks shm.

This can be triggered by TEEIOCSHMREGISTER with struct teeioctlshmregisterdata where length is 0.

Jump to errfreeshm instead.

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

drm/xe/display: fix oops in suspend/shutdown without display

The xe driver keeps track of whether to probe display, and whether display hardware is there, using xe->info.probedisplay. It gets set to false if there's no display after inteldisplaydeviceprobe(). However, the display may also be disabled via fuses, detected at a later time in inteldisplaydeviceinforuntimeinit().

In this case, the xe driver does foreachintelcrtc() on uninitialized mode config in xedisplayflushcleanupwork(), leading to a NULL pointer dereference, and generally calls display code with display info cleared.

Check for inteldisplaydevicepresent() after inteldisplaydeviceinforuntimeinit(), and reset xe->info.probedisplay as necessary. Also do unsetdisplayfeatures() for completeness, although display runtime init has already done that. This will need to be unified across all cases later.

Move inteldisplaydeviceinforuntimeinit() call slightly earlier, similar to i915, to avoid a bunch of unnecessary setup for no display cases.

Note #1: The xe driver has no business doing low level display plumbing like foreachintelcrtc() to begin with. It all needs to happen in display code.

Note #2: The actual bug is present already in commit 44e694958b95 ("drm/xe/display: Implement display support"), but the oops was likely introduced later at commit ddf6492e0e50 ("drm/xe/display: Make display suspend/resume work on discrete").

(cherry picked from commit 7c3eb9f47533220888a67266448185fd0775d4da)

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

drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups

v3drewritecsdjobwgcountsfromindirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs.

Jump to the cleanup path instead of returning directly, so the mappings are always dropped.

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

net/sched: actmirred: fix wrong device for macheaderxmit check in tcfblockcastredir

In tcfblockcastredir(), when iterating block ports to redirect packets to multiple devices, the macheaderxmit flag is queried from the wrong device. The loop sends to devprev but queries devismacheaderxmit(dev) — which is the NEXT device in the iteration, not the one being sent to.

This causes tcfmirredtodev() to make incorrect decisions about whether to push or pull the MAC header. When the block contains mixed device types (e.g., an ethernet veth and a tunnel device), intermediate devices get the wrong macheaderxmit flag, leading to skb header corruption. In the worst case, skbpushrcsum with an incorrect maclen can exhaust headroom and panic.

The last device in the loop is handled correctly (line 365-366 uses devismacheaderxmit(devprev)), confirming this is a copy-paste oversight for the intermediate devices.

Fix by using devprev instead of dev for the macheaderxmit query, consistent with the device actually being sent to.

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

drm/msm/gem: fix error handling in msmioctlgeminfogetmetadata()

msmioctlgeminfogetmetadata() always returns 0 regardless of errors. When copytouser() fails or the user buffer is too small, the error code stored in ret is ignored because the function unconditionally returns 0. This causes userspace to believe the ioctl succeeded when it did not.

Additionally, kmemdup() can return NULL on allocation failure, but the return value is not checked. This leads to a NULL pointer dereference in the subsequent copytouser() call.

Add the missing NULL check for kmemdup() and return ret instead of 0.

Note that the SET counterpart (msmioctlgeminfosetmetadata) correctly returns ret.

Patchwork: https://patchwork.freedesktop.org/patch/714478/

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

RDMA/mana: Fix manadestroywqobj() cleanup in manaibcreateqprss()

Sashiko points out there are two bugs here in the error unwind flow, both related to how the WQ table is unwound.

First there is a double i-- on the first failure path due to the while loop having a i--, remove it.

Second if manaibinstallcqcb() fails then manacreatewqobj() is not undone due to the above i--.

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

media: chips-media: wave5: Fix memory leak on codecinfo allocation failure

In wave5vpuopenenc() and wave5vpuopendec(), a vpu instance is allocated via kzalloc(). If the subsequent allocation for inst->codecinfo fails, the functions return -ENOMEM without freeing the previously allocated instance, causing a memory leak.

Fix this by calling kfree() on the instance in this error path to ensure it is properly released.

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:

scsi: ufs: core: Fix SError in ufshcdrtcwork() during UFS suspend

In ufshcdwlsuspend(), canceldelayedworksync() is called to cancel the UFS RTC work, but it is placed after ufshcdvopssuspend(hba, pmop, POSTCHANGE). This creates a race condition where ufshcdrtcwork() can still be running while ufshcdvopssuspend() is executing. When UFSHCDCAPCLKGATING is not supported, the condition !hba->clkgating.activereqs is always true, causing ufshcdupdatertc() to be executed. Since ufshcdvopssuspend() typically performs clock gating operations, executing ufshcdupdatertc() at that moment triggers an SError. The kernel panic trace is as follows:

Kernel panic - not syncing: Asynchronous SError Interrupt Call trace: dumpbacktrace+0xec/0x128 showstack+0x18/0x28 dumpstacklvl+0x40/0xa0 dumpstack+0x18/0x24 panic+0x148/0x374 nmipanic+0x3c/0x8c arm64serrorpanic+0x64/0x8c doserror+0xc4/0xc8 el1h64errorhandler+0x34/0x4c el1h64error+0x68/0x6c el1interrupt+0x20/0x58 el1h64irqhandler+0x18/0x24 el1h64irq+0x68/0x6c ktimeget+0xc4/0x12c ufshcdmcqsqstop+0x4c/0xec ufshcdmcqsqcleanup+0x64/0x1dc ufshcdclearcmd+0x38/0x134 ufshcdissuedevcmd+0x298/0x4d0 ufshcdexecdevcmd+0x1a4/0x1c4 ufshcdqueryattr+0xbc/0x19c ufshcdrtcwork+0x10c/0x1c8 processscheduledworks+0x1c4/0x45c workerthread+0x32c/0x3e8 kthread+0x120/0x1d8 retfromfork+0x10/0x20

Fix this by moving canceldelayedworksync() before the call to ufshcdvopssuspend(hba, pmop, PRECHANGE), ensuring the UFS RTC work is fully completed or cancelled at that point.

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

drm/xe/sync: Cleanup partially initialized sync on parse failure

xesyncentryparse() can allocate references (syncobj, fence, chain fence, or user fence) before hitting a later failure path. Several of those paths returned directly, leaving partially initialized state and leaking refs.

Route these error paths through a common freesync label and call xesyncentrycleanup(sync) before returning the error.

(cherry picked from commit f939bdd9207a5d1fc55cced5459858480686ce22)

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

media: chips-media: wave5: Fix PM runtime usage count underflow

Replace pmruntimeputsync() with pmruntimedontuseautosuspend() in the remove path to properly pair with pmruntimeuseautosuspend() from probe. This allows pmruntimedisable() to handle reference count cleanup correctly regardless of current suspend state.

The driver calls pmruntimeputsync() unconditionally in remove, but the device may already be suspended due to autosuspend configured in probe. When autosuspend has already suspended the device, the usage count is 0, and pmruntimeputsync() decrements it to -1.

This causes the following warning on module unload:

------------[ cut here ]------------ WARNING: CPU: 1 PID: 963 at kernel/kthread.c:1430 kthreaddestroyworker+0x84/0x98 ... vdec 30210000.video-codec: Runtime PM usage count underflow!

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

media: rockchip: rga: Fix possible ERRPTR dereference in rgabufinit()

rgagetframe() can return ERRPTR(-EINVAL) when buffer type is unsupported or invalid. rgabufinit() does not check the return value and unconditionally dereferences the pointer when accessing f->size.

Add proper ERRPTR checking and return the error to prevent dereferencing an invalid pointer.

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

media: chips-media: wave5: Fix device cleanup order to prevent kernel panic

Move video device unregistration to the beginning of the remove function to ensure all video operations are stopped before cleaning up the worker thread and disabling PM runtime. This prevents hardware register access after the device has been powered down.

In polling mode, the hrtimer periodically triggers wave5vputimercallback() which queues work to the kthread worker. The worker executes wave5vpuirqworkfn() which reads hardware registers via wave5vdireadregister().

The original cleanup order disabled PM runtime and powered down hardware before unregistering video devices. When autosuspend triggers and powers off the hardware, the video devices are still registered and the worker thread can still be triggered by the hrtimer, causing it to attempt reading registers from powered-off hardware. This results in a bus error (synchronous external abort) and kernel panic.

This causes random kernel panics during encoding operations:

Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP Modules linked in: wave5 rpmsgctrl rpmsgchar ... CPU: 0 UID: 0 PID: 1520 Comm: vpuirqthread Tainted: G M W pc : wave5vdireadregister+0x10/0x38 [wave5] lr : wave5vpuirqworkfn+0x28/0x60 [wave5] Call trace: wave5vdireadregister+0x10/0x38 [wave5] kthreadworkerfn+0xd8/0x238 kthread+0x104/0x120 retfromfork+0x10/0x20 Code: aa1e03e9 d503201f f9416800 8b214000 (b9400000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: synchronous external abort: Fatal exception

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

clk: rs9: Reserve 8 struct clkhw slots for for 9FGV0841

The 9FGV0841 has 8 outputs and registers 8 struct clkhw, make sure there are 8 slots for those newly registered clkhw pointers, else there is going to be out of bounds write when pointers 4..7 are set into struct rs9driverdata .clkdif[4..7] field.

Since there are other structure members past this struct clkhw pointer array, writing to .clkdif[4..7] fields corrupts both the struct rs9driverdata content and data around it, sometimes without crashing the kernel. However, the kernel does surely crash when the driver is unbound or during suspend.

Fix this, increase the struct clkhw pointer array size to the maximum output count of 9FGV0841, which is the biggest chip that is supported by this driver.

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

bnxten: set backing store type from query type

bnxthwrmfuncbackingstoreqcapsv2() stores resp->type from the firmware response in ctxm->type and later uses that value to index fixed backing-store metadata arrays such as ctxarr[] and bnxtbstoretotrace[].

ctxm->type is fixed by the current backing-store query type and matches the array index of ctx->ctxarr. Set ctxm->type from the current loop variable instead of depending on resp->type.

Also update the loop to advance type from nextvalidtype in the for statement, which keeps the control flow simpler for non-valid and unchanged entries.

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

netfilter: nftables: reject immediate NFQUEUE verdict

nftqueue is always used from userspace nftables to deliver the NFQUEUE verdict. Immediately emitting an NFQUEUE verdict is never used by the userspace nft tools, so reject immediate NFQUEUE verdicts.

The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NFQUEUE immediate verdicts to address this issue.

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

xfs: scrub: unlock dquot before early return in quota scrub

xchkquotaitem can return early after calling xchkfblockprocesserror. When that helper returns false, the function returned immediately without dropping dq->qqlock, which can leave the dquot lock held and risk lock leaks or deadlocks in later quota operations.

Fix this by unlocking dq->qqlock before the early return.

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

netfs: Fix kernel BUG in netfslimititer() for ITERKVEC iterators

When a process crashes and the kernel writes a core dump to a 9P filesystem, kernelwrite() creates an ITERKVEC iterator. This iterator reaches netfslimititer() via netfsunbufferedwrite(), which only handles ITERFOLIOQ, ITERBVEC and ITERXARRAY iterator types, hitting the BUG() for any other type.

Fix this by adding netfslimitkvec() following the same pattern as netfslimitbvec(), since both kvec and bvec are simple segment arrays with pointer and length fields. Dispatch it from netfslimititer() when the iterator type is ITERKVEC.

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

drm/imagination: Fix deadlock in soft reset sequence

The soft reset sequence is currently executed from the threaded IRQ handler, hence it cannot call disableirq() which internally waits for IRQ handlers, i.e. itself, to complete.

Use disableirqnosync() during a soft reset instead.

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

drm/imagination: Synchronize interrupts before suspending the GPU

The runtime PM suspend callback doesn't know whether the IRQ handler is in progress on a different CPU core and doesn't wait for it to finish.

Depending on timing, the IRQ handler could be running while the GPU is suspended, leading to kernel crashes when trying to access GPU registers. See example signature below.

In a power off sequence initiated by the runtime PM suspend callback, wait for any IRQ handlers in progress on other CPU cores to finish, by calling synchronizeirq().

At the same time, remove the runtime PM resume/put calls in the threaded IRQ handler. On top of not being the right approach to begin with, and being at the wrong place as they should have wrapped all GPU register accesses, the driver would hit a deadlock between synchronizeirq() being called from a runtime PM suspend callback, holding the device power lock, and the resume callback requiring the same.

Example crash signature on a TI AM68 SK platform:

[ 337.241218] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError [ 337.241239] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241246] Tainted: [M]=MACHINECHECK [ 337.241249] Hardware name: Texas Instruments AM68 SK (DT) [ 337.241252] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 337.241256] pc : pvrriscvirqpending+0xc/0x24 [ 337.241277] lr : pvrdeviceirqthreadhandler+0x64/0x310 [ 337.241282] sp : ffff800085b0bd30 [ 337.241284] x29: ffff800085b0bd50 x28: ffff0008070d9eab x27: ffff800083a5ce10 [ 337.241291] x26: ffff000806e48f80 x25: ffff0008070d9eac x24: 0000000000000000 [ 337.241296] x23: ffff0008068e9bf0 x22: ffff0008068e9bd0 x21: ffff800085b0bd30 [ 337.241301] x20: ffff0008070d9e00 x19: ffff0008068e9000 x18: 0000000000000001 [ 337.241305] x17: 637365645f656c70 x16: 0000000000000000 x15: ffff000b7df9ff40 [ 337.241310] x14: 0000a585fe3c0d0e x13: 000000999704f060 x12: 000000000002771a [ 337.241314] x11: 00000000000000c0 x10: 0000000000000af0 x9 : ffff800085b0bd00 [ 337.241318] x8 : ffff0008071175d0 x7 : 000000000000b955 x6 : 0000000000000003 [ 337.241323] x5 : 0000000000000000 x4 : 0000000000000002 x3 : 0000000000000000 [ 337.241327] x2 : ffff800080e39d20 x1 : ffff800080e3fc48 x0 : 0000000000000000 [ 337.241333] Kernel panic - not syncing: Asynchronous SError Interrupt [ 337.241337] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241342] Tainted: [M]=MACHINECHECK [ 337.241343] Hardware name: Texas Instruments AM68 SK (DT) [ 337.241345] Call trace: [ 337.241348] showstack+0x18/0x24 (C) [ 337.241357] dumpstacklvl+0x60/0x80 [ 337.241364] dumpstack+0x18/0x24 [ 337.241368] vpanic+0x124/0x2ec [ 337.241373] abort+0x0/0x4 [ 337.241377] addtaint+0x0/0xbc [ 337.241384] arm64serrorpanic+0x70/0x80 [ 337.241389] doserror+0x3c/0x74 [ 337.241392] el1h64errorhandler+0x30/0x48 [ 337.241400] el1h64error+0x6c/0x70 [ 337.241404] pvrriscvirqpending+0xc/0x24 (P) [ 337.241410] irqthreadfn+0x2c/0xb0 [ 337.241416] irqthread+0x170/0x334 [ 337.241421] kthread+0x12c/0x210 [ 337.241428] retfromfork+0x10/0x20 [ 337.241434] SMP: stopping secondary CPUs [ 337.241451] Kernel Offset: disabled [ 337.241453] CPU features: 0x040000,02002800,20002001,0400421b [ 337.241456] Memory Limit: none [ 337.457921] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---

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

soc: microchip: mpfs: Fix memory leak in mpfssyscontrollerprobe()

In mpfssyscontrollerprobe(), if ofgetmtddevicebynode() fails, the function returns immediately without freeing the allocated memory for syscontroller, leading to a memory leak.

Fix this by jumping to the outfree label to ensure the memory is properly freed.

Also, consolidate the error handling for the mboxrequestchannel() failure case to use the same label.

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

mm: thp: deny THP for files on anonymous inodes

filethpenabled() incorrectly allows THP for files on anonymous inodes (e.g. guestmemfd and secretmem). These files are created via allocfilepseudo(), which does not call getwriteaccess() and leaves inode->iwritecount at 0. Combined with SISREG(inode->imode) being true, they appear as read-only regular files when CONFIGREADONLYTHPFORFS is enabled, making them eligible for THP collapse.

Anonymous inodes can never pass the inodeisopenforwrite() check since their iwritecount is never incremented through the normal VFS open path. The right thing to do is to exclude them from THP eligibility altogether, since CONFIGREADONLYTHPFORFS was designed for real filesystem files (e.g. shared libraries), not for pseudo-filesystem inodes.

For guestmemfd, this allows khugepaged and MADVCOLLAPSE to create large folios in the page cache via the collapse path, but the guestmemfd fault handler does not support large folios. This triggers WARNONONCE(foliotestlarge(folio)) in kvmgmemfaultusermapping().

For secretmem, collapsefile() tries to copy page contents through the direct map, but secretmem pages are removed from the direct map. This can result in a kernel crash:

BUG: unable to handle page fault for address: ffff88810284d000 RIP: 0010:memcpyorig+0x16/0x130 Call Trace: collapsefile hpagecollapsescanfile madvisecollapse

Secretmem is not affected by the crash on upstream as the memory failure recovery handles the failed copy gracefully, but it still triggers confusing false memory failure reports:

Memory failure: 0x106d96f: recovery action for clean unevictable LRU page: Recovered

Check ISANONFILE(inode) in filethpenabled() to deny THP for all anonymous inode files.

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

xfs: check for deleted cursors when revalidating two btrees

The free space and inode btree repair functions will rebuild both btrees at the same time, after which it needs to evaluate both btrees to confirm that the corruptions are gone.

However, Jiaming Zhang ran syzbot and produced a crash in the second xchkallocbt call. His root-cause analysis is as follows (with minor corrections):

In xreprevalidateallocbt(), xchkallocbt() is called twice (first for BNOBT, second for CNTBT). The cause of this issue is that the first call nullified the cursor required by the second call.

Let's first enter xreprevalidateallocbt() via following call chain:

xfsfileioctl() -> xfsiocscrubvmetadata() -> xfsscrubmetadata() -> sc->ops->repaireval(sc) -> xreprevalidateallocbt()

xchkallocbt() is called twice in this function. In the first call:

/ Note that sc->sm->smtype is XFSSCRUBTYPEBNOPT now / xchkallocbt() -> xchkbtree() -> bs->scrubrec(bs, recp) -> xchkallocbtrec() -> xchkallocbtxref() -> xchkallocbtxrefother()

since smtype is XFSSCRUBTYPEBNOBT, pur is set to &sc->sa.cntcur. Kernel called xfsallocgetrec() and returned -EFSCORRUPTED. Call chain:

xfsallocgetrec() -> xfsbtreegetrec() -> xfsbtreecheckblock() -> (XFSISCORRUPT || XFSTESTERROR), the former is false and the latter is true, return -EFSCORRUPTED. This should be caused by ioctl$XFSIOCERRORINJECTION I guess.

Back to xchkallocbtxrefother(), after receiving -EFSCORRUPTED from xfsallocgetrec(), kernel called xchkshouldcheckxref(). In this function, curpp (points to sc->sa.cntcur) is nullified.

Back to xreprevalidateallocbt(), since sc->sa.cntcur has been nullified, it then triggered null-ptr-deref via xchkallocbt() (second call) -> xchkbtree().

So. The bnobt revalidation failed on a cross-reference attempt, so we deleted the cntbt cursor, and then crashed when we tried to revalidate the cntbt. Therefore, check for a null cntbt cursor before that revalidation, and mark the repair incomplete. Also we can ignore the second tree entirely if the first tree was rebuilt but is already corrupt.

Apply the same fix to xreprevalidateiallocbt because it has the same problem.

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

ice: fix devlink reload call trace

Commit 4da71a77fc3b ("ice: read internal temperature sensor") introduced internal temperature sensor reading via HWMON. icehwmoninit() was added to iceinitfeature() and icehwmonexit() was added to iceremove(). As a result if devlink reload is used to reinit the device and then the driver is removed, a call trace can occur.

BUG: unable to handle page fault for address: ffffffffc0fd4b5d Call Trace: string+0x48/0xe0 vsnprintf+0x1f9/0x650 sprintf+0x62/0x80 nameshow+0x1f/0x30 devattrshow+0x19/0x60

The call trace repeats approximately every 10 minutes when system monitoring tools (e.g., sadc) attempt to read the orphaned hwmon sysfs attributes that reference freed module memory.

The sequence is: 1. Driver load, icehwmoninit() gets called from iceinitfeature() 2. Devlink reload down, flow does not call iceremove() 3. Devlink reload up, icehwmoninit() gets called from iceinitfeature() resulting in a second instance 4. Driver unload, icehwmonexit() called from iceremove() leaving the first hwmon instance orphaned with dangling pointer

Fix this by moving icehwmonexit() from iceremove() to icedeinitfeatures() to ensure proper cleanup symmetry with icehwmoninit().

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

platform/x86/amd: Fix memory leak in wbrfrecord()

The tmp buffer is allocated using kcalloc() but is not freed if acpievaluatedsm() fails. This causes a memory leak in the error path.

Fix this by explicitly freeing the tmp buffer in the error handling path of acpievaluatedsm().

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

mm/userfaultfd: fix kmaplocal LIFO ordering for CONFIGHIGHPTE

With CONFIGHIGHPTE on 32-bit ARM, movepagespte() maps PTE pages using kmaplocalpage(), which requires unmapping in Last-In-First-Out order.

The current code maps dstpte first, then srcpte, but unmaps them in the same order (dstpte, srcpte), violating the LIFO requirement. This causes the warning in kunmaplocalindexed():

WARNING: CPU: 0 PID: 604 at mm/highmem.c:622 kunmaplocalindexed+0x178/0x17c addr \!= fixtovirt(FIXKMAPBEGIN + idx)

Fix this by reversing the unmap order to respect LIFO ordering.

This issue follows the same pattern as similar fixes: - commit eca6828403b8 ("crypto: skcipher - fix mismatch between mapping and unmapping order") - commit 8cf57c6df818 ("nilfs2: eliminate staggered calls to kunmap in nilfsrename")

Both of which addressed the same fundamental requirement that kmaplocal operations must follow LIFO ordering.