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

i2c: imx-lpi2c: mark I2C adapter when hardware is powered down

On some i.MX platforms, certain I2C client drivers keep a periodic workqueue which continues to trigger I2C transfers.

During system suspend/resume, there exists a time window between: - suspendnoirq and the system entering suspend - the system starting to resume and resumenoirq

In this window, the I2C controller resources such as clock and pinctrl may already be disabled or not yet restored.

If a workqueue triggers an I2C transfer in this period, the driver attempts to access I2C registers while the hardware resources are unavailable, which may lead to system hang.

Mark the I2C adapter as suspended during noirq suspend and block new transfers until resume, ensuring that I2C transfers are only issued when hardware resources are available.

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

fuse-uring: fix EFAULT clobber in fuseuringcommit

copyfromuser() returns the number of bytes not copied as an unsigned residual on failure (1..sizeof(struct fuseoutheader)). fuseuringcommit stores that residual in ssizet err, sets req->out.h.error to -EFAULT, then jumps to out: with err still holding the positive residual.

err = copyfromuser(&req->out.h, &ent->headers->inout, sizeof(req->out.h)); if (err) { req->out.h.error = -EFAULT; goto out; / err is the positive residual / } ... out: fuseuringreqend(ent, req, err);

fuseuringreqend() then runs

if (error) req->out.h.error = error;

which overwrites the just-assigned -EFAULT with the positive residual. FUSE callers such as fusesimplerequest() test err < 0 to detect failure, so the positive value is interpreted as success and the caller proceeds with an uninitialised or partial req->out.args.

Fix by assigning err = -EFAULT in the failure branch before jumping to out, so fuseuringreqend() receives a negative errno and sets req->out.h.error to -EFAULT.

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

fuse-uring: end fusereq on io-uring cancel task work

When iouring delivers task work with tw.cancel set (PFEXITING, PFKTHREAD fallback, or percpurefisdying on the ring context), fuseuringsendintask() takes the cancel branch, assigns -ECANCELED, and falls through to fuseuringsend(). That path only flips the entry to FRRSUSERSPACE and completes the iouring cmd; it never discharges the ring entry's owning reference to the fusereq that fuseuringaddreqtoringent() handed it at dispatch time.

fuseuringsendintask() tw.cancel == true err = -ECANCELED fuseuringsend(ent, cmd, err, issueflags) ent->state = FRRSUSERSPACE listmove(&ent->list, &queue->entinuserspace) ent->cmd = NULL iouringcmddone(-ECANCELED) / ent->fusereq still set, req still hashed /

The fusereq stays linked on fpq->processing[hash] and fuserequestend() is never invoked. The originating syscall thread blocks in D-state in requestwaitanswer() until fuseabortconn() runs, which can be the entire connection lifetime. For FRBACKGROUND requests fc->numbackground is never decremented either, so repeated cancels inflate the counter until maxbackground is hit and all later background ops stall. tw.cancel does not imply a connection abort (e.g. a single iouring worker thread exits while the fuse connection stays up), so this cannot be left for fuseabortconn() to clean up.

Ending the req but still routing the entry through fuseuringsend() is not enough: that leaves a req-less entry on entinuserspace, and entlistrequestexpired() dereferences ent->fusereq unconditionally on the head of that list, which would then NULL-deref.

Fix the cancel branch to release the entry directly. Remove it from the queue, complete the iouring cmd, end the fusereq, free the entry, and drop its queuerefs (waking the teardown waiter if it was the last).

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

netfs, afs: Fix write skipping in dir/link writepages

Fix netfswritesingle() and afssinglewritepages() to better handle a write that would be skipped due to lock contention and WBSYNCNONE by returning 1 from netfswritesingle() if it skipped and making afssinglewritepages() skip also. If a skip occurs, the inode must be re-marked as the VFS may have cleared the mark.

This is really only theoretical for directories in netfswritesingle() as the only path to that is through afssinglewritepages() that takes the ->validatelock around it, thereby serialising it.

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

netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets

When calling netlblconnsetattr(), addr->safamily is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipsosocksetattr() is triggered. Inside this function, the following code is executed:

skfullsock(sk) ? inetsk(sk)->pinet6 : NULL;

Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference.

This patch fixes the issue by checking if inet6sk(sk) returns a NULL pointer before accessing pinet6.

arcnet: Add NULL check in com20020pciprobe()

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

thermal: int340x: Add NULL check for adev

Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL").

Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402thermalprobe().

Note, under the same directory, int3400thermalprobe() has such a check.

[ rjw: Subject edit, added Fixes: ]

clk: samsung: Fix UBSAN panic in samsungclkinit()

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

remoteproc: core: Clear tablesz when rprocshutdown

There is case as below could trigger kernel dump: Use U-Boot to start remote processor(rproc) with resource table published to a fixed address by rproc. After Kernel boots up, stop the rproc, load a new firmware which doesn't have resource table ,and start rproc.

When starting rproc with a firmware not have resource table, memcpy(loadedtable, rproc->cachedtable, rproc->tablesz) will trigger dump, because rproc->cachetable is set to NULL during the last stop operation, but rproc->tablesz is still valid.

This issue is found on i.MX8MP and i.MX9.

Dump as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : pimemcpygeneric+0x110/0x22c lr : rprocstart+0x88/0x1e0 Call trace: pimemcpygeneric+0x110/0x22c (P) rprocboot+0x198/0x57c statestore+0x40/0x104 devattrstore+0x18/0x2c sysfskfwrite+0x7c/0x94 kernfsfopwriteiter+0x120/0x1cc vfswrite+0x240/0x378 ksyswrite+0x70/0x108 arm64syswrite+0x1c/0x28 invokesyscall+0x48/0x10c el0svccommon.constprop.0+0xc0/0xe0 doel0svc+0x1c/0x28 el0svc+0x30/0xcc el0t64synchandler+0x10c/0x138 el0t64sync+0x198/0x19c

Clear rproc->tablesz to address the issue.

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

regulator: tps65219: fix irqdata.rdev not being assigned

Commit 64a6b577490c ("regulator: tps65219: Remove debugging helper function") removed the tps65219getrdevbyname() helper along with the irqdata.rdev assignment that depended on it. This left irqdata.rdev uninitialized for all IRQs, causing undefined behavior when regulatornotifiercallchain() is called from the IRQ handler:

Internal error: Oops: 0000000096000004 pc : regulatornotifiercallchain lr : tps65219regulatorirqhandler Call trace: regulatornotifiercallchain tps65219regulatorirqhandler handlenestedirq regmapirqthread irqthreadfn irqthread kthread retfromfork

Instead of restoring a dedicated lookup array, restructure the probe function to combine regulator registration with IRQ registration in the same loop. This way the rdev returned by devmregulatorregister() is naturally available for assigning to irqdata.rdev without any auxiliary data structure.

Non-regulator IRQs (SENSOR, TIMEOUT) that don't correspond to any registered regulator are registered with rdev=NULL, and the IRQ handler is protected with a NULL check to avoid crashing.

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

i2c: davinci: fix division by zero on missing clock-frequency

When the 'clock-frequency' property is missing from the device tree, the driver falls back to DAVINCII2CDEFAULTBUSFREQ. However, this macro was defined in kHz (100), whereas the device tree property is expected in Hz.

The probe function divided the fallback value by 1000, causing integer truncation that resulted in dev->busfreq = 0. This triggered a deterministic division-by-zero kernel panic when calculating clock dividers later in the probe sequence.

Fix this by redefining DAVINCII2CDEFAULTBUSFREQ in Hz (100000) to match the expected device tree property unit, allowing the existing division logic to work correctly for both cases.

drm/amdkfd: debugfs hanghws skip GPU with MES

drm/amdgpu: handle amdgpucgscreatedevice() errors in amdpowerplaycreate()

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

RDMA/mlx5: Fix pagesize variable overflow

Change all variables storing mlx5umemmkcfindbestpgsz() result to unsigned long to support values larger than 31 and avoid overflow.

For example: If we try to register 4GB of memory that is contiguous in physical memory, the driver will optimize the pagesize and try to use an mkey with 4GB entity size. The 'unsigned int' pagesize variable will overflow to '0' and we'll hit the WARNON() in alloccacheablemr().

WARNING: CPU: 2 PID: 1203 at drivers/infiniband/hw/mlx5/mr.c:1124 alloccacheablemr+0x22/0x580 [mlx5ib] Modules linked in: mlx5ib mlx5core bonding ip6gre ip6tunnel tunnel6 ipgre gre rdmarxe rdmaucm ibuverbs ibipoib ibumad rpcrdma ibiser libiscsi scsitransportiscsi rdmacm iwcm ibcm fuse ibcore [last unloaded: mlx5core] CPU: 2 UID: 70878 PID: 1203 Comm: rdmaresourcel Tainted: G W 6.14.0-rc4-dirty #43 Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:alloccacheablemr+0x22/0x580 [mlx5ib] Code: 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 41 52 53 48 83 ec 30 f6 46 28 04 4c 8b 77 08 75 21 &lt;0f&gt; 0b 49 c7 c2 ea ff ff ff 48 8d 65 d0 4c 89 d0 5b 41 5a 41 5c 41 RSP: 0018:ffffc900006ffac8 EFLAGS: 00010246 RAX: 0000000004c0d0d0 RBX: ffff888217a22000 RCX: 0000000000100001 RDX: 00007fb7ac480000 RSI: ffff8882037b1240 RDI: ffff8882046f0600 RBP: ffffc900006ffb28 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000007e0 R11: ffffea0008011d40 R12: ffff8882037b1240 R13: ffff8882046f0600 R14: ffff888217a22000 R15: ffffc900006ffe00 FS: 00007fb7ed013340(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb7ed1d8000 CR3: 00000001fd8f6006 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: &lt;TASK&gt; ? warn+0x81/0x130 ? alloccacheablemr+0x22/0x580 [mlx5ib] ? reportbug+0xfc/0x1e0 ? handlebug+0x55/0x90 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? alloccacheablemr+0x22/0x580 [mlx5ib] createrealmr+0x54/0x150 [mlx5ib] ibuverbsregmr+0x17f/0x2a0 [ibuverbs] ibuverbshandlerUVERBSMETHODINVOKEWRITE+0xca/0x140 [ibuverbs] ibuverbsrunmethod+0x6d0/0x780 [ibuverbs] ? pfxibuverbshandlerUVERBSMETHODINVOKEWRITE+0x10/0x10 [ibuverbs] ibuverbscmdverbs+0x19b/0x360 [ibuverbs] ? walksystemramrange+0x79/0xd0 ? pteoffsetmap+0x1b/0x110 ? pteoffsetmaplock+0x80/0x100 ibuverbsioctl+0xac/0x110 [ibuverbs] x64sysioctl+0x94/0xb0 dosyscall64+0x50/0x110 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7fb7ecf0737b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 2a 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffdbe03ecc8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffdbe03edb8 RCX: 00007fb7ecf0737b RDX: 00007ffdbe03eda0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffdbe03ed80 R08: 00007fb7ecc84010 R09: 00007ffdbe03eed4 R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffdbe03eed4 R13: 000000000000000c R14: 000000000000000c R15: 00007fb7ecc84150 &lt;/TASK&gt;

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

drm/xe/regsr: Fix leak on xastore failure

Free the newly allocated entry when xastore() fails to avoid a memory leak on the error path.

v2: use goto failfree. (Bala)

(cherry picked from commit 6bc6fec71ac45f52db609af4e62bdb96b9f5fadb)

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

wifi: mt76: fix deadlock in remain-on-channel

mt76remainonchannel() and mt76roccomplete() call mt76setchannel() while already holding dev->mutex. Since mt76setchannel() also acquires dev->mutex, this results in a deadlock.

Use mt76setchannel() instead of mt76setchannel(). Add canceldelayedworksync() for macwork before acquiring the mutex in mt76remainonchannel() to prevent a secondary deadlock with the macwork workqueue.

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

net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY

DSA has 2 kinds of drivers:

1. Those who call dsaswitchsuspend() and dsaswitchresume() from their device PM ops: qca8k-8xxx, bcmsf2, microchip ksz 2. Those who don't: all others. The above methods should be optional.

For type 1, dsaswitchsuspend() calls dsausersuspend() -> phylinkstop(), and dsaswitchresume() calls dsauserresume() -> phylinkstart(). These seem good candidates for setting macmanagedpm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on.

Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdiobusphysuspend() and mdiobusphyresume() should run in full), I have noticed that the following warning from mdiobusphyresume() is triggered:

WARNON(phydev->state != PHYHALTED && phydev->state != PHYREADY && phydev->state != PHYUP);

because the PHY state machine is running.

It's running as a result of a previous dsauseropen() -> ... -> phylinkstart() -> phystart() having been initiated by the user.

The previous mdiobusphysuspend() was supposed to have called phystopmachine(), but it didn't. So this is why the PHY is in state PHYNOLINK by the time mdiobusphyresume() runs.

mdiobusphysuspend() did not call phystopmachine() because for phylink, the phydev->adjustlink function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resume"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARNON(), it would have likely been invisible.

This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming macmanagedpm is set correctly, a quick search indicates the following other drivers might be affected:

$ grep -Zlr PHYLINKNETDEV drivers/ | xargs -0 grep -L macmanagedpm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5main.c drivers/net/ethernet/microchip/lan966x/lan966xmain.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fsenet/fsenet-main.c drivers/net/ethernet/freescale/dpaa/dpaaeth.c drivers/net/ethernet/freescale/uccgeth.c drivers/net/ethernet/freescale/enetc/enetcpfcommon.c drivers/net/ethernet/marvell/mvpp2/mvpp2main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/presteramain.c drivers/net/ethernet/mediatek/mtkethsoc.c drivers/net/ethernet/altera/alteratsemain.c drivers/net/ethernet/wangxun/txgbe/txgbephy.c drivers/net/ethernet/meta/fbnic/fbnicphylink.c drivers/net/ethernet/tehuti/tn40phy.c drivers/net/ethernet/mscc/ocelotnet.c

Make the existing conditions dependent on the PHY device having a phydev->phylinkchange() implementation equal to the default phylinkchange() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylinkphychange() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phylinkchange() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test.

Thus, for the situation where the PM is not managed b ---truncated---

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

net: Fix null-ptr-deref by socklockinitclassandname() and rmmod.

When I ran the repro [0] and waited a few seconds, I observed two LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]

Reproduction Steps:

1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables rule

At step 3), the CIFS module calls sockrelease() for the underlying TCP socket, and it returns quickly. However, the socket remains in FINWAIT1 because incoming FIN packets are dropped.

At this point, the module's refcnt is 0 while the socket is still alive, so the following rmmod command succeeds.

# ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445

# lsmod | grep cifs cifs 1159168 0

This highlights a discrepancy between the lifetime of the CIFS module and the underlying TCP socket. Even after CIFS calls sockrelease() and it returns, the TCP socket does not die immediately in order to close the connection gracefully.

While this is generally fine, it causes an issue with LOCKDEP because CIFS assigns a different lock class to the TCP socket's sk->sklock using socklockinitclassandname().

Once an incoming packet is processed for the socket or a timer fires, sk->sklock is acquired.

Then, LOCKDEP checks the lock context in checkwaitcontext(), where hlockclass() is called to retrieve the lock class. However, since the module has already been unloaded, hlockclass() logs a warning and returns NULL, triggering the null-ptr-deref.

If LOCKDEP is enabled, we must ensure that a module calling socklockinitclassandname() (CIFS, NFS, etc) cannot be unloaded while such a socket is still alive to prevent this issue.

Let's hold the module reference in socklockinitclassandname() and release it when the socket is freed in skprotfree().

Note that socklockinit() clears sk->skowner for svccreatesocket() that calls socklockinitclassandname() for a listening socket, which clones a socket by skclonelock() without GFPZERO.

[0]: CIFSSERVER="10.0.0.137" CIFSPATH="//${CIFSSERVER}/Users/Administrator/Desktop/CIFSTEST" DEV="enp0s3" CRED="/root/WindowsCredential.txt"

MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFSPATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echointerval=1

iptables -A INPUT -s ${CIFSSERVER} -j DROP

for i in $(seq 10); do umount ${MNT} rmmod cifs sleep 1 done

rm -r ${MNT}

iptables -D INPUT -s ${CIFSSERVER} -j DROP

[1]: DEBUGLOCKSWARNON(1) WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlockclass (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) Modules linked in: cifsarc4 nlsucs2utils cifsmd4 [last unloaded: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:hlockclass (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... Call Trace: <IRQ> lockacquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lockacquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) rawspinlocknested (kernel/locking/spinlock.c:379) tcpv4rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcpipv4.c:2350) ...

BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: errorcode(0x0000) - not-present page PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:lockacquire (kernel/ ---truncated---

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

PCI: brcmstb: Fix error path after a call to regulatorbulkget()

If the regulatorbulkget() returns an error and no regulators are created, we need to set their number to zero.

If we don't do this and the PCIe link up fails, a call to the regulatorbulkfree() will result in a kernel panic.

While at it, print the error value, as we cannot return an error upwards as the kernel will WARN() on an error from addbus().

[kwilczynski: commit log, use comma in the message to match style with other similar messages]

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

net: mvpp2: Prevent parser TCAM memory corruption

Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM information, from concurrent modifications.

Both the TCAM and SRAM tables are indirectly accessed by configuring an index register that selects the row to read or write to. This means that operations must be atomic in order to, e.g., avoid spreading writes across multiple rows. Since the shadow SRAM array is used to find free rows in the hardware table, it must also be protected in order to avoid TOCTOU errors where multiple cores allocate the same row.

This issue was detected in a situation where mvpp2setrxmode() ran concurrently on two CPUs. In this particular case the MVPP2PEMACUCPROMISCUOUS entry was corrupted, causing the classifier unit to drop all incoming unicast - indicated by the rxclassifierdrops counter.

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

x86/kexec: Push kjump return address even for non-kjump kexec

The version of purgatory code shipped by kexec-tools attempts to look above the top of its stack to find a return address for a kjump, even in a non-kjump kexec.

After the commit in Fixes: the word above the stack might not be there, leading to a fault (which is at least now caught by my exception-handling code in kexec).

That commit fixed things for the actual kjump path, but no longer "gratuitously" pushes the unused return address to the stack in the non-kjump path. Put that back in the non-kjump path, to prevent purgatory from crashing when trying to access it.

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

drm/v3d: Fix global performance monitor reference counting

In the SETGLOBAL ioctl, v3dperfmonfind() bumps the reference count on the perfmon it returns, but v3dperfmonsetglobalioctl() and v3dperfmondelete() fail to release that reference on several paths:

1. v3dperfmonsetglobalioctl() leaks the reference on its error paths.

2. CLEARGLOBAL leaks both the find reference and the reference previously stashed in v3d->globalperfmon by the SETGLOBAL ioctl that configured it.

3. Destroying a perfmon that is the current global perfmon leaks the reference stashed by the SETGLOBAL ioctl.

Release each of these references explicitly.

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

xfrm: iptfs: fix ABBA deadlock in iptfsdestroystate()

iptfsdestroystate() calls hrtimercancel() while holding a spinlock that the timer callback also acquires, leading to an ABBA deadlock on SMP systems.

For the output timer (iptfstimer): - iptfsdestroystate() holds x->lock, calls hrtimercancel() - iptfsdelaytimer() callback takes x->lock

For the drop timer (droptimer): - iptfsdestroystate() holds droplock, calls hrtimercancel() - iptfsdroptimer() callback takes droplock

Both timers use HRTIMERMODERELSOFT, so their callbacks run in softirq context. When hrtimercancel() is called for a soft timer that is currently executing on another CPU, hrtimercancelwaitrunning() spins on softirqexpirylock -- the same lock held by the softirq running the callback. If the callback is blocked waiting for the spinlock held by the caller of hrtimercancel(), a circular dependency forms:

CPU 0: holds lockA -> waits for softirqexpirylock CPU 1: holds softirqexpirylock -> waits for lockA

Fix by calling hrtimercancel() before acquiring the respective locks. hrtimercancel() is safe to call without holding any lock and will wait for any in-progress callback to complete. For the output timer, the lock is still acquired afterwards to drain the packet queue. For the drop timer, the lock/unlock pair is removed entirely since it only existed to serialize with the timer callback, which hrtimercancel() already guarantees.

Found by source code audit.

bonding: check xdp prog when set bond mode

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

nfsd: don't ignore the return code of svcprocregister()

Currently, nfsdprocstatinit() ignores the return value of svcprocregister(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later.

Fix nfsdprocstatinit() to return the same type of pointer as svcprocregister(), and fix up nfsdnetinit() to check that and fail the nfsdnet construction if it occurs.

svcprocregister() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsdnet construction codepath, so if this happens, return -ENOMEM.

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

accel/amdxdna: Fix potential NULL pointer dereference in context cleanup

aiedestroycontext() is invoked during error handling in aie2createcontext(). However, aiedestroycontext() assumes that the context's mailbox channel pointer is non-NULL. If mailbox channel creation fails, the pointer remains NULL and calling aiedestroycontext() can lead to a NULL pointer dereference.

In aie2createcontext(), replace aiedestroycontext() with a function which request firmware to remove the context created previously.

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

thermal/of: Fix reference leak in thermalofcmlookup()

In thermalofcmlookup(), trnp is obtained via ofparsephandle(), but never released.

Use the free(devicenode) cleanup attribute to automatically release the node and fix the leak.

[ rjw: Changelog edits ]

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

platform/chrome: crosectypec: Init mutex in Thunderbolt registration

crostypecregisterthunderbolt() missed initializing the adata->lock mutex. This leads to a NULL dereference when the mutex is later acquired (e.g. in crostypecaltmodework()).

Initialize the mutex in crostypecregisterthunderbolt() to fix the issue.

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

smb: client: use kzalloc to zero-initialize security descriptor buffer

Commit 62e7dd0a39c2d ("smb: common: change the data type of numaces to le16") split struct smbacl's le32 numaces field into le16 numaces and le16 reserved. The reserved field corresponds to Sbz2 in the MS-DTYP ACL wire format, which must be zero [1].

When building an ACL descriptor in buildsecdesc(), we are using a kmalloc()'ed descriptor buffer and writing the fields explicitly using le16() writes now. This never writes to the 2 byte reserved field, leaving it as uninitialized heap data.

When the reserved field happens to contain non-zero slab garbage, Samba rejects the security descriptor with "ndrpullsecuritydescriptor failed: Range Error", causing chmod to fail with EINVAL.

Change kmalloc() to kzalloc() to ensure the entire buffer is zero-initialized.

[1] https://learn.microsoft.com/en-us/openspecs/windowsprotocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428

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

mm/damon/core: fix damoncall() vs kdamondfn() exit race

Patch series "mm/damon/core: fix damoncall()/damoswalk() vs kdmond exit race".

damoncall() and damoswalk() can leak memory and/or deadlock when they race with kdamond terminations. Fix those.

This patch (of 2);

When kdamondfn() main loop is finished, the function cancels all remaining damoncall() requests and unset the damonctx->kdamond so that API callers and API functions themselves can know the context is terminated. damoncall() adds the caller's request to the queue first. After that, it shows if the kdamond of the damonctx is still running (damonctx->kdamond is set). Only if the kdamond is running, damoncall() starts waiting for the kdamond's handling of the newly added request.

The damoncall() requests registration and damonctx->kdamond unset are protected by different mutexes, though. Hence, damoncall() could race with damonctx->kdamond unset, and result in deadlocks.

For example, let's suppose kdamond successfully finished the damoncall() requests cancelling. Right after that, damoncall() is called for the context. It registers the new request, and shows the context is still running, because damonctx->kdamond unset is not yet done. Hence the damoncall() caller starts waiting for the handling of the request. However, the kdamond is already on the termination steps, so it never handles the new request. As a result, the damoncall() caller threads infinitely waits.

Fix this by introducing another damonctx field, namely callcontrolsobsolete. It is protected by the damonctx->callcontrolslock, which protects damoncall() requests registration. Initialize (unset) it in kdamondfn() before letting damonstart() returns and set it just before the cancelling of remaining damoncall() requests is executed. damoncall() reads the obsolete field under the lock and avoids adding a new request.

After this change, only requests that are guaranteed to be handled or cancelled are registered. Hence the after-registration DAMON context termination check is no longer needed. Remove it together.

Note that the deadlock will not happen when damoncall() is called for repeat mode request. In tis case, damoncall() returns instead of waiting for the handling when the request registration succeeds and it shows the kdamond is running. However, if the request also has dealloconcancel, the request memory would be leaked.

The issue is found by sashiko [1].