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---

ext4: fix OOB read when checking dotdot dir

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:

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: ]

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:

x86/mm/pat: Fix VMPAT handling when fork() fails in copypagerange()

If trackpfncopy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables.

Consequently untrackpfn() will see VMPAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied.

The easiest fix would be to simply clear the VMPAT flag of the dst VMA if trackpfncopy() fails. However, the whole thing is about "simply" clearing the VMPAT flag is shaky as well: if we passed trackpfncopy() and performed a reservation, but copying the page tables fails, we'll simply clear the VMPAT flag, not properly undoing the reservation ... which is also wrong.

So let's fix it properly: set the VMPAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VMPAT flag after undoing the reservation.

Note that any copied page table entries will get zapped when the VMA will get removed later, after copypagerange() succeeded; as VMPAT is not set then, we won't try cleaning VMPAT up once more and untrackpfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run.

A reproducer can trigger this usually at the first try:

https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/patfork.c

WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 getpatinfo+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:getpatinfo+0xf6/0x110 ... Call Trace: <TASK> ... untrackpfn+0x52/0x110 unmapsinglevma+0xa6/0xe0 unmapvmas+0x105/0x1f0 exitmmap+0xf6/0x460 mmput+0x4b/0x120 copyprocess+0x1bf6/0x2aa0 kernelclone+0xab/0x440 dosysclone+0x66/0x90 dosyscall64+0x95/0x180

Likely this case was missed in:

d155df53f310 ("x86/mm/pat: clear VMPAT if copyp4drange failed")

... and instead of undoing the reservation we simply cleared the VMPAT flag.

Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like trackpfnremap/untrackpfn separately.

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

vhost-scsi: Fix handling of multiple calls to vhostscsisetendpoint

If vhostscsisetendpoint is called multiple times without a vhostscsiclearendpoint between them, we can hit multiple bugs found by Haoran Zhang:

1. Use-after-free when no tpgs are found:

This fixes a use after free that occurs when vhostscsisetendpoint is called more than once and calls after the first call do not find any tpgs to add to the vstpg. When vhostscsisetendpoint first finds tpgs to add to the vstpg array match=true, so we will do:

vhostvqsetbackend(vq, vstpg); ...

kfree(vs->vstpg); vs->vstpg = vstpg;

If vhostscsisetendpoint is called again and no tpgs are found match=false so we skip the vhostvqsetbackend call leaving the pointer to the vstpg we then free via:

kfree(vs->vstpg); vs->vstpg = vstpg;

If a scsi request is then sent we do:

vhostscsihandlevq -> vhostscsigetreq -> vhostvqgetbackend

which sees the vstpg we just did a kfree on.

2. Tpg dir removal hang:

This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1.

The problem is that if vhostscsisetendpoint detects a tpg is already in the vs->vstpg array or if the tpg has been removed so targetdependitem fails, the undepend goto handler will do targetundependitem on all tpgs in the vstpg array dropping their refcount to 0. At this time vstpg contains both the tpgs we have added in the current vhostscsisetendpoint call as well as tpgs we added in previous calls which are also in vs->vstpg.

Later, when vhostscsiclearendpoint runs it will do targetundependitem on all the tpgs in the vs->vstpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir.

3. Tpg leak:

This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhostscsisetendpoint is called multiple times but with different target names.

The bug occurs if a user has called VHOSTSCSISETENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOSTSCSISETENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vstpg array. Later when we do vhostscsiclearendpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vstpg. We will then return from the function without doing targetundependitem on the tpgs.

Because of all these bugs, it looks like being able to call vhostscsisetendpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhostscsisetendpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhostscsiclearendpoint first.

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:

netfilter: nfttunnel: fix geneveopt type confusion addition

When handling multiple NFTATUNNELKEYOPTSGENEVE attributes, the parsing logic should place every geneveopt structure one by one compactly. Hence, when deciding the next geneveopt position, the pointer addition should be in units of char .

However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write.

[ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nfttunnelobjinit+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] <TASK> [ 6.992586] dumpstacklvl+0x44/0x5c [ 6.992801] printreport+0x184/0x4be [ 6.993790] kasanreport+0xc5/0x100 [ 6.994252] kasancheckrange+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nfttunnelobjinit+0x977/0xa70 [ 6.995677] nftobjinit+0x10c/0x1b0 [ 6.995891] nftablesnewobj+0x585/0x950 [ 6.996922] nfnetlinkrcvbatch+0xdf9/0x1020 [ 6.998997] nfnetlinkrcv+0x1df/0x220 [ 6.999537] netlinkunicast+0x395/0x530 [ 7.000771] netlinksendmsg+0x3d0/0x6d0 [ 7.001462] socksendmsg+0x99/0xa0 [ 7.001707] syssendmsg+0x409/0x450 [ 7.002391] syssendmsg+0xfd/0x170 [ 7.003145] syssendmsg+0xea/0x170 [ 7.004359] dosyscall64+0x5e/0x90 [ 7.005817] entrySYSCALL64afterhwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIGRAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8

Fix this bug with correct pointer addition and conversion in parse and dump code.

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

net: fix geneveopt length integer overflow

struct geneveopt uses 5 bit length for each single option, which means every vary size option should be smaller than 128 bytes.

However, all current related Netlink policies cannot promise this length condition and the attacker can exploit a exact 128-byte size option to fake a zero length option and confuse the parsing logic, further achieve heap out-of-bounds read.

One example crash log is like below:

[ 3.905425] ================================================================== [ 3.905925] BUG: KASAN: slab-out-of-bounds in nlaput+0xa9/0xe0 [ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177 [ 3.906646] [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1 [ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 3.907784] Call Trace: [ 3.907925] &lt;TASK&gt; [ 3.908048] dumpstacklvl+0x44/0x5c [ 3.908258] printreport+0x184/0x4be [ 3.909151] kasanreport+0xc5/0x100 [ 3.909539] kasancheckrange+0xf3/0x1a0 [ 3.909794] memcpy+0x1f/0x60 [ 3.909968] nlaput+0xa9/0xe0 [ 3.910147] tunnelkeydump+0x945/0xba0 [ 3.911536] tcfactiondump1+0x1c1/0x340 [ 3.912436] tcfactiondump+0x101/0x180 [ 3.912689] tcfextsdump+0x164/0x1e0 [ 3.912905] fwdump+0x18b/0x2d0 [ 3.913483] tcffillnode+0x2ee/0x460 [ 3.914778] tfilternotify+0xf4/0x180 [ 3.915208] tcnewtfilter+0xd51/0x10d0 [ 3.918615] rtnetlinkrcvmsg+0x4a2/0x560 [ 3.919118] netlinkrcvskb+0xcd/0x200 [ 3.919787] netlinkunicast+0x395/0x530 [ 3.921032] netlinksendmsg+0x3d0/0x6d0 [ 3.921987] socksendmsg+0x99/0xa0 [ 3.922220] syssendto+0x1b7/0x240 [ 3.922682] x64syssendto+0x72/0x90 [ 3.922906] dosyscall64+0x5e/0x90 [ 3.923814] entrySYSCALL64afterhwframe+0x6e/0xd8 [ 3.924122] RIP: 0033:0x7e83eab84407 [ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 &lt;5b&gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIGRAX: 000000000000002c [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407 [ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003 [ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0 [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8

Fix these issues by enforing correct length condition in related policies.

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

iptunnel: adapt iptunnelxmitstats() to NETDEVPCPUSTATDSTATS

Blamed commits forgot that vxlan/geneve use udptunnel[6]xmitskb() which call iptunnelxmitstats().

iptunnelxmitstats() was assuming tunnels were only using NETDEVPCPUSTATTSTATS.

@syncp offset in pcpuswnetstats and pcpudstats is different.

32bit kernels would either have corruptions or freezes if the syncp sequence was overwritten.

This patch also moves pcpustattype closer to dev->{t,d}stats to avoid a potential cache line miss since iptunnelxmitstats() needs to read it.

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

KVM: arm64: Tear down vGIC on failed vCPU creation

If kvmarchvcpucreate() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU.

Add the missing cleanup to kvmarchvcpucreate(), ensuring that the vGIC vCPU structures are destroyed on error.

btrfs: harden blockgroup::bglist against listdel() races

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

PM: hibernate: Avoid deadlock in hibernatecompressorparamset()

syzbot reported a deadlock in locksystemsleep() (see below).

The write operation to "/sys/module/hibernate/parameters/compressor" conflicts with the registration of ieee80211 device, resulting in a deadlock when attempting to acquire systemtransitionmutex under paramlock.

To avoid this deadlock, change hibernatecompressorparamset() to use mutextrylock() for attempting to acquire systemtransitionmutex and return -EBUSY when it fails.

Task flags need not be saved or adjusted before calling mutextrylock(&systemtransitionmutex) because the caller is not going to end up waiting for this mutex and if it runs concurrently with system suspend in progress, it will be frozen properly when it returns to user space.

syzbot report:

syz-executor895/5833 is trying to acquire lock: ffffffff8e0828c8 (systemtransitionmutex){+.+.}-{4:4}, at: locksystemsleep+0x87/0xa0 kernel/power/main.c:56

but task is already holding lock: ffffffff8e07dc68 (paramlock){+.+.}-{4:4}, at: kernelparamlock kernel/params.c:607 [inline] ffffffff8e07dc68 (paramlock){+.+.}-{4:4}, at: paramattrstore+0xe6/0x300 kernel/params.c:586

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #3 (paramlock){+.+.}-{4:4}: mutexlockcommon kernel/locking/mutex.c:585 [inline] mutexlock+0x19b/0xb10 kernel/locking/mutex.c:730 ieee80211ratecontrolopsget net/mac80211/rate.c:220 [inline] ratecontrolalloc net/mac80211/rate.c:266 [inline] ieee80211initratectrlalg+0x18d/0x6b0 net/mac80211/rate.c:1015 ieee80211registerhw+0x20cd/0x4060 net/mac80211/main.c:1531 mac80211hwsimnewradio+0x304e/0x54e0 drivers/net/wireless/virtual/mac80211hwsim.c:5558 initmac80211hwsim+0x432/0x8c0 drivers/net/wireless/virtual/mac80211hwsim.c:6910 dooneinitcall+0x128/0x700 init/main.c:1257 doinitcalllevel init/main.c:1319 [inline] doinitcalls init/main.c:1335 [inline] dobasicsetup init/main.c:1354 [inline] kernelinitfreeable+0x5c7/0x900 init/main.c:1568 kernelinit+0x1c/0x2b0 init/main.c:1457 retfromfork+0x45/0x80 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244

-> #2 (rtnlmutex){+.+.}-{4:4}: mutexlockcommon kernel/locking/mutex.c:585 [inline] mutexlock+0x19b/0xb10 kernel/locking/mutex.c:730 wgpmnotification drivers/net/wireguard/device.c:80 [inline] wgpmnotification+0x49/0x180 drivers/net/wireguard/device.c:64 notifiercallchain+0xb7/0x410 kernel/notifier.c:85 notifiercallchainrobust kernel/notifier.c:120 [inline] blockingnotifiercallchainrobust kernel/notifier.c:345 [inline] blockingnotifiercallchainrobust+0xc9/0x170 kernel/notifier.c:333 pmnotifiercallchainrobust+0x27/0x60 kernel/power/main.c:102 snapshotopen+0x189/0x2b0 kernel/power/user.c:77 miscopen+0x35a/0x420 drivers/char/misc.c:179 chrdevopen+0x237/0x6a0 fs/chardev.c:414 dodentryopen+0x735/0x1c40 fs/open.c:956 vfsopen+0x82/0x3f0 fs/open.c:1086 doopen fs/namei.c:3830 [inline] pathopenat+0x1e88/0x2d80 fs/namei.c:3989 dofilpopen+0x20c/0x470 fs/namei.c:4016 dosysopenat2+0x17a/0x1e0 fs/open.c:1428 dosysopen fs/open.c:1443 [inline] dosysopenat fs/open.c:1459 [inline] sesysopenat fs/open.c:1454 [inline] x64sysopenat+0x175/0x210 fs/open.c:1454 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

-> #1 ((pmchainhead).rwsem){++++}-{4:4}: downread+0x9a/0x330 kernel/locking/rwsem.c:1524 blockingnotifiercallchainrobust kerne ---truncated---

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

scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue

When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash.

Add flag 'ioadminresetsync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.

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

wifi: mt76: mt7921/mt7925: fix NULL dereference in CSA beacon

This patch is based on a BUG as reported by Bongani Hlope at https://lore.kernel.org/all/20260502125824.425d7159@bongani-mini.home.org.za/

When a channel-switch announcement (CSA) beacon is received, cfg80211 queues a wiphy work item that eventually calls mt7921channelswitchrxbeacon(). If the station disconnects (or the channel context is otherwise torn down) between the time the work is queued and the time it runs, the driver's dev->newctx pointer can already have been cleared to NULL. mt7921channelswitchrxbeacon() then dereferences newctx unconditionally, triggering a NULL pointer dereference at address 0x0:

BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:mt7921channelswitchrxbeacon+0x1f/0x100 [mt7921common]

The same missing guard exists in mt7925channelswitchrxbeacon(), which shares the same code pattern introduced by the same commit.

Add an early-return NULL check for dev->newctx in both mt7921channelswitchrxbeacon() and mt7925channelswitchrxbeacon(). When newctx is NULL there is no pending channel switch to process, so returning immediately is the correct and safe action.

Oops-Analysis: http://oops.fenrus.org/reports/lkml/20260502125824.425d7159@bongani-mini.home.org.za/report.html

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

perf/aux: Fix page UAF in maprange()

maprange() reads rb->auxpages[], rb->auxnrpages and rb->auxpgoff via perfmmaptopage() while holding only event->mmapmutex. Those fields are serialized by rb->auxmutex, and mmapmutex is per event.

Thus, two events sharing one rb via PERFEVENTIOCSETOUTPUT can race rballocaux() with maprange(), leading to a page-UAF scenario as follows:

CPU 0 CPU 1 ===== ===== rballocaux() maprange() [1]: allocate rb->auxpages[0] [2]: rb->auxnrpages++ [3]: perfmmaptopage() returns rb->auxpages[0] [4]: map it as VMPFNMAP [5]: rb->auxpgoff = 1

munmap the page [6]: free rb->auxpages[0]

Pages mapped as VMPFNMAP have no refcount protection, so CPU 1 holds a mapping to a freed physical frame.

Fix this by taking rb->auxmutex across the page walk in maprange().

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

bpf: Keep dynamic inner array lookups nullable

An ARRAYOFMAPS can use an array created with BPFFINNERMAP as its inner map template. A concrete inner array with a different maxentries value can then replace the template.

After a successful outer map lookup, the verifier represents the resulting map pointer using the inner map template. Const-key lookup nullness elision consequently uses the template maxentries even though the runtime helper uses the concrete inner map maxentries.

Do not elide lookup result nullness for maps marked with BPFFINNERMAP, because the template maxentries does not prove that the key is in bounds for the concrete runtime map.

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

netfs: Fix cancellation of a DIO and single read subrequests

When the preparation of a new subrequest for a read fails, if the subrequest has already been added to the stream->subrequests list, it can't simply be put and abandoned as the collector may see it. Also, if it hasn't been queued yet, it has two outstanding refs that both need to be put. Both DIO read and single-read dispatch fail at this; further, both differ in the order they do things to the way buffered read works.

Fix cancellation of both DIO-read and single-read subrequests that failed preparation by the following steps:

(1) Harmonise all three reads (buffered, dio, single) to queue the subreq before prepping it.

(2) Make all three call netfsqueueread() to do the queuing.

(3) Set NETFSRREQALLQUEUED independently of the queuing as we don't know the length of the subreq at this point.

(4) In all cases, set the error and NETFSSREQFAILED flag on the subreq and then call netfsreadsubreqterminated() to deal with it. This will pass responsibility off to the collector for dealing with it.

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

fprobe: Fix unregisterfprobe() to wait for RCU grace period

Commit 4346ba1604093 ("fprobe: Rewrite fprobe on function-graph tracer") changed fprobe to register struct fprobe to an rcu-hlist, but it forgot to wait for RCU GP. Thus there can be use-after-free if the fprobe is released right after unregistering. This can be happened on fprobe event and sample module code.

To fix this issue, add synchronizercu() in unregisterfprobe().

Note that BPF is OK because fprobe is used as a part of bpfkprobemultilink. This unregisters its fprobe in bpfkprobemultilinkrelease() and it is deallocated via bpfkprobemultilinkdealloc(), which is invoked from bpflinkdeferdeallocrcugp() RCU callback.

For BPF, this also introduced unregisterfprobeasync() which does NOT wait for RCU grace priod.

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

afs: Fix the locking used by afsgetlink()

The afs filesystem in the kernel doesn't do locking correctly for symbolic links. There are a number of problems:

(1) It doesn't do any locking around afsreadsingle() to prevent races between multiple ->getlink() calls, thereby allowing the possibility of leaks.

(2) It doesn't use RCU barriering when accessing the buffer pointers during RCU pathwalk.

(3) It can race with another thread updating the contents of the symlink if a third party updated it on the server.

Fix this by the following means:

(0) Move symlink handling into its own file as this makes it more complicated.

(1) Take the validatelock around afsreadsingle() to prevent races between multiple ->getlink() calls.

(2) Keep a separate copy of the symlink contents with an rcuhead. This is always going to be a lot smaller than a page, so it can be kmalloc'd and save quite a bit of memory. It also needs a refcount for non-RCU pathwalk.

(3) Split the symlink read and write-to-cache routines in afs from those for directories.

(4) Discard the I/O buffer as soon as the write-to-cache completes as this is a full page (plus a folioqueue).

(5) If there's no cache, discard the I/O buffer immediately after reading and copying if there is no cache.

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

x86/mce: use iscopyfromuser() to determine copy-from-user context

Patch series "mm/hwpoison: Fix regressions in memory failure handling", v4.

1. What am I trying to do:

This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS.

- copyin case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetching in user space

2. What is the expected outcome and why

- For copyin case:

Kernel can recover from poison found where kernel is doing getuser() or copyfromuser() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EXTYPEUACCESS is found, the PC jumps to recovery code specified in ASMEXTABLEFAULT() and return a -EFAULT to user space.

- For instr case:

If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage.

3. What actually happens and why

- For copyin case: kernel panic since v5.17

Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EXTYPEEFAULTREG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EXTYPEUACCESS to EXTYPEEFAULTREG. It breaks previous EXTYPEUACCESS handling when posion found in getuser() or copyfromuser().

- For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race

When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed.

Background: why UNcorrected errors tied to CMCI in Intel platform [1]

Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR.

Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to #CMCI. Just to add to the confusion, Linux does take an action (in ucdecodenotifier()) to try to offline the page despite the UCNA signature name.

Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1]

Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a "real" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read.

Thus:

1) Core is clever and thinks address A is needed soon, issues a speculative read.

2) Core finds it is going to use address A soon after sending the read request

3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A.

Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison).

Why user process is killed for instr case

Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not ---truncated---

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

net: stmmac: Fix accessing freed irq affinityhint

In stmmacrequestirqmultimsi(), a pointer to the stack variable cpumask is passed to irqsetaffinityhint(). This value is stored in irqdesc->affinityhint, but once stmmacrequestirqmultimsi() returns, the pointer becomes dangling.

The affinityhint is exposed via procfs with SIRUGO permissions, allowing any unprivileged process to read it. Accessing this stale pointer can lead to:

- a kernel oops or panic if the referenced memory has been released and unmapped, or - leakage of kernel data into userspace if the memory is re-used for other purposes.

All platforms that use stmmac with PCI MSI (Intel, Loongson, etc) are affected.

bonding: check xdp prog when set bond mode

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

net: decrease cached dst counters in dstrelease

Upstream fix ac888d58869b ("net: do not delay dstentriesadd() in dstrelease()") moved decrementing the dst count from dstdestroy to dstrelease to avoid accessing already freed data in case of netns dismantle. However in case CONFIGDSTCACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts:

Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpucounteraddbatch+0x3c/0x160 (P) dstrelease+0xec/0x108 dstcachedestroy+0x68/0xd8 dstdestroy+0x13c/0x168 dstdestroyrcu+0x1c/0xb0 rcudobatch+0x18c/0x7d0 rcucore+0x174/0x378 rcucoresi+0x18/0x30

Fix this by invalidating the cache, and thus decrementing cached dst counters, in dstrelease too.

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:

usb: xhci: Apply the link chain quirk on NEC isoc endpoints

Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment:

[ 1.041954] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhcihcd: AMD-Vi: Event logged [IOPAGEFAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhcihcd: AMD-Vi: Event logged [IOPAGEFAULT domain=0x0005 address=0xffa09040 flags=0x0000]

It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.

[ 7.041671] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhcihcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 31 [ 7.042144] xhcihcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 31 [ 7.042266] xhcihcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820

At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.

[ 7.098130] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 13 [ 7.098132] xhcihcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 13 [ 7.098256] xhcihcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhcihcd: Overrun event on slot 1 ep 2

It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain.

Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board.

[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhcihcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVEROK cmdage=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 physseg 5 prio class 0

Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set.

The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times.

No ne ---truncated---

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

media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization

On Mediatek devices with a system companion processor (SCP) the mtkscp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization.

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.