Bluetooth: L2CAP: Fix deadlock in l2capconndel()

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

mm: call ->freefolio() directly in foliounmapinvalidate()

We can only call filemapfreefolio() if we have a reference to (or hold a lock on) the mapping. Otherwise, we've already removed the folio from the mapping so it no longer pins the mapping and the mapping can be removed, causing a use-after-free when accessing mapping->aops.

Follow the same pattern as removemapping() and load the freefolio function pointer before dropping the lock on the mapping. That lets us make filemapfreefolio() static as this was the only caller outside filemap.c.

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

igb: remove napisynchronize() in igbdown()

When an AFXDP zero-copy application terminates abruptly (e.g., kill -9), the XSK buffer pool is destroyed but NAPI polling continues. igbcleanrxirqzc() repeatedly returns the full budget, preventing napicompletedone() from clearing NAPISTATESCHED.

igbdown() calls napisynchronize() before napidisable() for each queue vector. napisynchronize() spins waiting for NAPISTATESCHED to clear, which never happens. igbdown() blocks indefinitely, the TX watchdog fires, and the TX queue remains permanently stalled.

napidisable() already handles this correctly: it sets NAPISTATEDISABLE. After a full-budget poll, napipoll() checks napidisablepending(). If set, it forces completion and clears NAPISTATESCHED, breaking the loop that napisynchronize() cannot.

napisynchronize() was added in commit 41f149a285da ("igb: Fix possible panic caused by Rx traffic arrival while interface is down"). napidisable() provides stronger guarantees: it prevents further scheduling and waits for any active poll to exit. Other Intel drivers (ixgbe, ice, i40e) use napidisable() without a preceding napisynchronize() in their down paths.

Remove redundant napisynchronize() call and reorder napidisable() before igbsetqueuenapi() so the queue-to-NAPI mapping is only cleared after polling has fully stopped.

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

kthread: consolidate kthread exit paths to prevent use-after-free

Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rbnode with an 8-byte rhashhead in struct pid, shrinking it from 160 to 144 bytes.

struct kthread (without CONFIGBLKCGROUP) is also 144 bytes. With CONFIGSLABMERGEDEFAULT and SLABHWCACHEALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinitynode both sit at offset 0x78.

When a kthread exits via maketaskdead() it bypasses kthreadexit() and misses the affinitynode cleanup. freekthreadstruct() frees the memory while the node is still linked into the global kthreadaffinitylist. A subsequent listdel() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer.

Instead of patching freekthreadstruct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthreadexit() into a macro that calls doexit() and add kthreaddoexit() which is called from doexit() for any task with PFKTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - maketaskdead(), direct doexit(), or kthreadexit().

Replace tokthread() with a new tskiskthread() accessor in the public header. Export doexit() since module code using the kthreadexit() macro now needs it directly.

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

batman-adv: Avoid double-rtnllock ELP metric worker

batadvvelpgetthroughput() might be called when the RTNL lock is already held. This could be problematic when the work queue item is cancelled via canceldelayedworksync() in batadvvelpifacedisable(). In this case, an rtnllock() would cause a deadlock.

To avoid this, rtnltrylock() was used in this function to skip the retrieval of the ethtool information in case the RTNL lock was already held.

But for cfg80211 interfaces, batadvgetrealnetdev() was called - which also uses rtnllock(). The approach for ethtoolgetlinkksettings() must also be used instead and the lockless version batadvgetrealnetdev() has to be called.

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

xfrm: iptfs: fix skbput() panic on non-linear skb during reassembly

In iptfsreassemcont(), IP-TFS attempts to append data to the new inner packet 'newskb' that is being reassembled. First a zero-copy approach is tried if it succeeds then newskb becomes non-linear.

When a subsequent fragment in the same datagram does not meet the fast-path conditions, a memory copy is performed. It calls skbput() to append the data and as newskb is non-linear it triggers SKBLINEARASSERT check.

Oops: invalid opcode: 0000 [#1] SMP NOPTI [...] RIP: 0010:skbput+0x3c/0x40 [...] Call Trace: <IRQ> iptfsreassemcont+0x1ab/0x5e0 [xfrmiptfs] iptfsinputordered+0x2af/0x380 [xfrmiptfs] iptfsinput+0x122/0x3e0 [xfrmiptfs] xfrminput+0x91e/0x1a50 xfrm4esprcv+0x3a/0x110 ipprotocoldeliverrcu+0x1d7/0x1f0 iplocaldeliverfinish+0xbe/0x1e0 netifreceiveskbcore.constprop.0+0xb56/0x1120 netifreceiveskblistcore+0x133/0x2b0 netifreceiveskblistinternal+0x1ff/0x3f0 napicompletedone+0x81/0x220 virtnetpoll+0x9d6/0x116e [virtionet] napipoll.constprop.0+0x2b/0x270 netrxaction+0x162/0x360 handlesoftirqs+0xdc/0x510 irqexitrcu+0xe7/0x110 irqexitrcu+0xe/0x20 commoninterrupt+0x85/0xa0 </IRQ> <TASK>

Fix this by checking if the skb is non-linear. If it is, linearize it by calling skblinearize(). As the initial allocation of newskb originally reserved enough tailroom for the entire reassembled packet we do not need to check if we have enough tailroom or extend it.

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

dmaengine: idxd: Fix crash when the event log is disabled

If reporting errors to the event log is not supported by the hardware, and an error that causes Function Level Reset (FLR) is received, the driver will try to restore the event log even if it was not allocated.

Also, only try to free the event log if it was properly allocated.

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

xfrm: iptfs: validate inner IPv4 header length in IPTFS payload

Add validation of the inner IPv4 packet totlen and ihl fields parsed from decrypted IPTFS payloads in inputprocesspayload(). A crafted ESP packet containing an inner IPv4 header with totlen=0 causes an infinite loop: iplen=0 leads to capturelen=min(0, remaining)=0, so the data offset never advances and the while(data < tail) loop never terminates, spinning forever in softirq context.

Reject inner IPv4 packets where totlen < ihl4 or ihl4 < sizeof(struct iphdr), which catches both the totlen=0 case and malformed ihl values. The normal IP stack performs this validation in iprcvcore(), but IPTFS extracts and processes inner packets before they reach that layer.

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

xfrm: iptfs: only publish modedata after clone setup

iptfsclonestate() stores x->modedata before allocating the reorder window. If that allocation fails, the code frees the cloned state and returns -ENOMEM, leaving x->modedata pointing at freed memory.

The xfrm clone unwind later runs destroystate() through x->modedata, so the failed clone path tears down IPTFS state that clonestate() already freed.

Keep the cloned IPTFS state private until all allocations succeed so failed clones leave x->modedata unset. The destroy path already handles a NULL modedata pointer.

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

dmaengine: idxd: Fix possible invalid memory access after FLR

In the case that the first Function Level Reset (FLR) concludes correctly, but in the second FLR the scratch area for the saved configuration cannot be allocated, it's possible for a invalid memory access to happen.

Always set the deallocated scratch area to NULL after FLR completes.

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

serial: 8250: Fix TX deadlock when using DMA

dmaengineterminateasync does not guarantee that the dmatxcomplete callback will run. The callback is currently the only place where dma->txrunning gets cleared. If the transaction is canceled and the callback never runs, then dma->txrunning will never get cleared and we will never schedule new TX DMA transactions again.

This change makes it so we clear dma->txrunning after we terminate the DMA transaction. This is "safe" because serial8250txdmaflush is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to dma->txrunning is serialized.

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.

ext4: fix OOB read when checking dotdot dir

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:

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:

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] <TASK> [ 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 <5b> 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:

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:

mailbox: mchp-ipc-sbi: fix out-of-bounds access in mchpipcgetclusteraggrirq()

The clustercfg array is dynamically allocated to hold per-CPU configuration structures, with its size based on the number of online CPUs. Previously, this array was indexed using hartid, which may be non-contiguous or exceed the bounds of the array, leading to out-of-bounds access. Switch to using cpuid as the index, as it is guaranteed to be within the valid range provided by foreachonlinecpu().

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

arm64: dts: qcom: monaco: Reserve full Gunyah metadata region

We observe spurious "Synchronous External Abort" exceptions (ESR=0x96000010) and kernel crashes on Monaco-based platforms. These faults are caused by the kernel inadvertently accessing hypervisor-owned memory that is not properly marked as reserved.

From boot log, The Qualcomm hypervisor reports the memory range at 0x91a80000 of size 0x80000 (512 KiB) as hypervisor-owned: qheehypassignremovememory: 0x91a80000/0x80000 -> ret 0

However, the EFI memory map provided by firmware only reserves the subrange 0x91a40000–0x91a87fff (288 KiB). The remaining portion (0x91a88000–0x91afffff) is incorrectly reported as conventional memory (from efi debug): efi: 0x000091a40000-0x000091a87fff [Reserved...] efi: 0x000091a88000-0x0000938fffff [Conventional...]

As a result, the allocator may hand out PFNs inside the hypervisor owned region, causing fatal aborts when the kernel accesses those addresses.

Add a reserved-memory carveout for the Gunyah hypervisor metadata at 0x91a80000 (512 KiB) and mark it as no-map so Linux does not map or allocate from this area.

For the record: Hyp version: gunyah-e78adb36e debug (2025-11-17 05:38:05 UTC) UEFI Ver: 6.0.260122.BOOT.MXF.1.0.c1-00449-KODIAKLA-1

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

KVM: arm64: Eagerly init vgic dist/redist on vgic creation

If vgicallocateprivateirqslocked() fails for any odd reason, we exit kvmvgiccreate() early, leaving dist->rdregions uninitialised.

kvmvgicdistdestroy() then comes along and walks into the weeds trying to free the RDs. Got to love this stuff.

Solve it by moving all the static initialisation early, and make sure that if we fail halfway, we're in a reasonable shape to perform the rest of the teardown. While at it, reset the vgic model on failure, just in case...

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

mm/damon/core: clear walkcontrol on inactive context in damoswalk()

damoswalk() sets ctx->walkcontrol to the caller-provided control structure before checking whether the context is running. If the context is inactive (damonisrunning() returns false), the function returns -EINVAL without clearing ctx->walkcontrol. This leaves a dangling pointer to a stack-allocated structure that will be freed when the caller returns.

This is structurally identical to the bug fixed in commit f9132fbc2e83 ("mm/damon/core: remove callcontrol in inactive contexts") for damoncall(), which had the same pattern of linking a control object and returning an error without unlinking it.

The dangling walkcontrol pointer can cause: 1. Use-after-free if the context is later started and kdamond    dereferences ctx->walkcontrol (e.g., in damoswalkcancel()    which writes to control->canceled and calls complete()) 2. Permanent -EBUSY from subsequent damoswalk() calls, since the    stale pointer is non-NULL

Nonetheless, the real user impact is quite restrictive. The use-after-free is impossible because there is no damoswalk() callers who starts the context later. The permanent -EBUSY can actually confuse users, as DAMON is not running. But the symptom is kept only while the context is turned off. Turning it on again will make DAMON internally uses a newly generated damonctx object that doesn't have the invalid damoswalkcontrol pointer, so everything will work fine again.

Fix this by clearing ctx->walkcontrol under walkcontrollock before returning -EINVAL, mirroring the fix pattern from f9132fbc2e83.

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

spi: rockchip-sfc: Fix double-free in remove() callback

The driver uses devmspiregistercontroller() for registration, which automatically unregisters the controller via devm cleanup when the device is removed. The manual call to spiunregistercontroller() in the remove() callback can lead to a double-free.

And to make sure controller is unregistered before DMA buffer is unmapped, switch to use spiregistercontroller() in probe().

drm/vkms: Fix use after free and double free on init error

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

memstick: rtsxusbms: Fix slab-use-after-free in rtsxusbmsdrvremove

This fixes the following crash:

================================================================== BUG: KASAN: slab-use-after-free in rtsxusbmspollcard+0x159/0x200 [rtsxusbms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241

CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNEDMODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsxusbmspollcard [rtsxusbms] Call Trace: <TASK> dumpstacklvl+0x51/0x70 printaddressdescription.constprop.0+0x27/0x320 ? rtsxusbmspollcard+0x159/0x200 [rtsxusbms] printreport+0x3e/0x70 kasanreport+0xab/0xe0 ? rtsxusbmspollcard+0x159/0x200 [rtsxusbms] rtsxusbmspollcard+0x159/0x200 [rtsxusbms] ? pfxrtsxusbmspollcard+0x10/0x10 [rtsxusbms] ? pfxschedule+0x10/0x10 ? kickpool+0x3b/0x270 processonework+0x357/0x660 workerthread+0x390/0x4c0 ? pfxworkerthread+0x10/0x10 kthread+0x190/0x1d0 ? pfxkthread+0x10/0x10 retfromfork+0x2d/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 161446: kasansavestack+0x20/0x40 kasansavetrack+0x10/0x30 kasankmalloc+0x7b/0x90 kmallocnoprof+0x1a7/0x470 memstickallochost+0x1f/0xe0 [memstick] rtsxusbmsdrvprobe+0x47/0x320 [rtsxusbms] platformprobe+0x60/0xe0 calldriverprobe+0x35/0x120 reallyprobe+0x123/0x410 driverprobedevice+0xc7/0x1e0 driverprobedevice+0x49/0xf0 deviceattachdriver+0xc6/0x160 busforeachdrv+0xe4/0x160 deviceattach+0x13a/0x2b0 busprobedevice+0xbd/0xd0 deviceadd+0x4a5/0x760 platformdeviceadd+0x189/0x370 mfdadddevice+0x587/0x5e0 mfdadddevices+0xb1/0x130 rtsxusbprobe+0x28e/0x2e0 [rtsxusb] usbprobeinterface+0x15c/0x460 calldriverprobe+0x35/0x120 reallyprobe+0x123/0x410 driverprobedevice+0xc7/0x1e0 driverprobedevice+0x49/0xf0 deviceattachdriver+0xc6/0x160 busforeachdrv+0xe4/0x160 deviceattach+0x13a/0x2b0 rebindmarkedinterfaces.isra.0+0xcc/0x110 usbresetdevice+0x352/0x410 usbdevdoioctl+0xe5c/0x1860 usbdevioctl+0xa/0x20 x64sysioctl+0xc5/0xf0 dosyscall64+0x59/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

Freed by task 161506: kasansavestack+0x20/0x40 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x36/0x60 kasanslabfree+0x34/0x50 kfree+0x1fd/0x3b0 devicerelease+0x56/0xf0 kobjectcleanup+0x73/0x1c0 rtsxusbmsdrvremove+0x13d/0x220 [rtsxusbms] platformremove+0x2f/0x50 devicereleasedriverinternal+0x24b/0x2e0 busremovedevice+0x124/0x1d0 devicedel+0x239/0x530 platformdevicedel.part.0+0x19/0xe0 platformdeviceunregister+0x1c/0x40 mfdremovedevicesfn+0x167/0x170 deviceforeachchildreverse+0xc9/0x130 mfdremovedevices+0x6e/0xa0 rtsxusbdisconnect+0x2e/0xd0 [rtsxusb] usbunbindinterface+0xf3/0x3f0 devicereleasedriverinternal+0x24b/0x2e0 procdisconnectclaim+0x13d/0x220 usbdevdoioctl+0xb5e/0x1860 usbdevioctl+0xa/0x20 x64sysioctl+0xc5/0xf0 dosyscall64+0x59/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

Last potentially related work creation: kasansavestack+0x20/0x40 kasanrecordauxstack+0x85/0x90 insertwork+0x29/0x100 queuework+0x34a/0x540 calltimerfn+0x2a/0x160 expiretimers+0x5f/0x1f0 runtimerbase.part.0+0x1b6/0x1e0 runtimersoftirq+0x8b/0xe0 handlesoftirqs+0xf9/0x360 irqexitrcu+0x114/0x130 sysvecapictimerinterrupt+0x72/0x90 asmsysvecapictimerinterrupt+0x16/0x20

Second to last potentially related work creation: kasansavestack+0x20/0x40 kasanrecordauxstack+0x85/0x90 insertwork+0x29/0x100 queuework+0x34a/0x540 calltimerfn+0x2a/0x160 expiretimers+0x5f/0x1f0 runtimerbase.part.0+0x1b6/0x1e0 runtimersoftirq+0x8b/0xe0 handlesoftirqs+0xf9/0x ---truncated---

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:

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:

cachefiles: Fix potential UAF/KASAN warning

Currently, tracecachefilescoherency() is being passed a pointer to a be64 lain over the coherency data in struct cachefilesxattr so that it can display the first 8 bytes. However, the data is of variable length and could even be 0 bytes. This could lead to a UAF or KASAN warning.

Fix this by making sure the buffer has room for at least 8 bytes and that those 8 bytes are pre-cleared.

Further, those bytes are not 8-byte aligned, so fix the tracepoint to extract the data as four 2-byte words (they are 2-byte aligned) and reassemble the be64. The compiler will convert this into a single 8-byte load where the CPU supports it.