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

signal: clear JOBCTLPENDINGMASK for caller in zapotherthreads()

When a multi-threaded process receives a stop signal (e.g., SIGSTOP), dosignalstop() sets JOBCTLSTOPPENDING and JOBCTLSTOPCONSUME on all threads and sets signal->groupstopcount to the number of threads. If one of the threads concurrently calls execve(), dethread() invokes zapotherthreads() to kill all other threads. zapotherthreads() aborts the pending group stop by resetting signal->groupstopcount to 0 and clears the JOBCTLPENDINGMASK for all other threads. However, it fails to clear the job control flags for the calling thread.

When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTLSTOPPENDING flag, it calls dosignalstop(), which invokes taskparticipategroupstop(). Since JOBCTLSTOPCONSUME is still set, it attempts to decrement the already-zero signal->groupstopcount, triggering a warning:

sig->groupstopcount == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 taskparticipategroupstop+0x215/0x2d0 Call Trace: <TASK> dosignalstop+0x3be/0x5c0 kernel/signal.c:2619 getsignal+0xa8c/0x1330 kernel/signal.c:2884 archdosignalorrestart+0xbc/0x840 arch/x86/kernel/signal.c:337 exittousermodeloop+0x8c/0x4d0 kernel/entry/common.c:98 dosyscall64+0x33e/0xf80 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

Fix this race condition by clearing the JOBCTLPENDINGMASK for the calling thread in zapotherthreads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zapprocess() and completesignal(), which correctly clear these flags for all threads including the current one.

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

netfilter: synproxy: add mutex to guard hook reference counting

As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other.

Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.

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

netfilter: nftfib: fix stale stack leak via the OIFNAME register

For NFTFIBRESULTOIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTNLOCAL and oif-mismatch paths nftfib{4,6}eval() only writes one register via "dest = 0". The remaining three registers are left as whatever was on the stack in nftdochain()'s struct nftregs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace.

The NFTAFIBFPRESENT existence check has the same shape: it is only meaningful for NFTFIBRESULTOIF, yet it was accepted for any result type while the eval stores a single byte via nftregstore8(), leaving the rest of the declared span stale.

Fix both:

- replace the bare "dest = 0" in the eval with nftfibstoreresult(), which strscpypad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and

- restrict NFTAFIBFPRESENT to NFTFIBRESULTOIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.

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

netfilter: xtables: avoid leaking percpu counter pointers

The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot.

On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by xtables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace.

Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.

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

netfilter: nftct: fix missing expect put in obj eval

nftctexpectobjeval() allocates an expectation and may call nfctexpectrelated(), but never drops its local reference.

Add nfctexpectput(exp) before return to balance allocation.

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

ipc/shm: serialize orphan cleanup with shmnattch updates

shmdestroyorphaned() walks the shm idr under shmids(ns).rwsem, but that does not serialize all fields tested by shmmaydestroy(). In particular, shmnattch is updated while holding shmperm.lock, and attach paths can do that without holding the rwsem.

Do not decide that an orphaned segment is unused before taking the object lock. Move the shmmaydestroy() check under shmperm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.

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

hwmon: (pmbus/adm1266) reject implausible blackbox recordcount

adm1266nvmemreadblackbox() loops over a recordcount that comes straight from byte 3 of the BLACKBOXINFO response. The destination buffer is data->devmem, sized for the nvmem cell's declared 2048 bytes (ADM1266BLACKBOXMAXRECORDS ADM1266BLACKBOXSIZE = 32 64). A device that reports a recordcount greater than 32 -- whether due to firmware bugs, bus corruption, or a non-responsive slave returning 0xff -- would walk readbuff past the end of the devmem allocation on the trailing iterations.

Cap recordcount at ADM1266BLACKBOXMAXRECORDS (introduced here) before entering the loop and return -EIO on any larger value, so a malformed BLACKBOXINFO response cannot drive the loop out of bounds.

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

netfs: Fix netfsinvalidatefolio() to clear dirty bit if all changes gone

If a streaming write is made, this will leave the relevant modified folio in a not-uptodate, but dirty state with a netfsfolio struct hung off of folio->private indicating the dirty range. Subsequently truncating the file such that the dirty data in the folio is removed, but the first part of the folio theoretically remains will cause the netfsfolio struct to be discarded... but will leave the dirty flag set.

If the folio is then read via mmap(), netfsreadfolio() will see that the page is dirty and jump to netfsreadgaps() to fill in the missing bits. netfsreadgaps(), however, expects there to be a netfsfolio struct present and can oops because truncate removed it.

Fix this by calling foliocanceldirty() in netfsinvalidatefolio() in the event that all the dirty data in the folio is erased (as nfs does).

Also add some tracepoints to log modifications to a dirty page.

This can be reproduced with something like:

dd if=/dev/zero of=/xfstest.test/foo bs=1M count=1 umount /xfstest.test mount /xfstest.test xfsio -c "w 0xbbbf 0xf96c" \ -c "truncate 0xbbbf" \ -c "mmap -r 0xb000 0x11000" \ -c "mr 0xb000 0x11000" \ /xfstest.test/foo

with fscaching disabled (otherwise streaming writes are suppressed) and a change to netfsperformwrite() to disallow streaming writes if the fd is open ORDWR:

if (//(file->fmode & FMODEREAD) || <--- comment this out netfsiscacheenabled(ctx)) {

It should be reproducible even without this change, but if prevents the above trivial xfsio command from reproducing it.

Note that the initial dd is important: the file must start out sufficiently large that the zero-point logic doesn't just clear the gaps because it knows there's nothing in the file to read yet. Unmounting and mounting is needed to clear the pagecache (there are other ways to do that that may also work).

This was initially reproduced with the generic/522 xfstest on some patches that remove the FMODEREAD restriction.

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

netfs: fix VMBUGONFOLIO() issue in netfswritebegin() call

The multiple runs of generic/013 test-case is capable to reproduce a kernel BUG at mm/filemap.c:1504 with probability of 30%.

while true; do sudo ./check generic/013 done

[ 9849.452376] page: refcount:3 mapcount:0 mapping:00000000e58ff252 index:0x10781 pfn:0x1c322 [ 9849.452412] memcg:ffff8881a1915800 [ 9849.452417] aops:cephaops ino:1000058db9e dentry name(?):"f9XXXXXX" [ 9849.452432] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) [ 9849.452441] raw: 0017ffffc0000000 0000000000000000 dead000000000122 ffff88816110d248 [ 9849.452445] raw: 0000000000010781 0000000000000000 00000003ffffffff ffff8881a1915800 [ 9849.452447] page dumped because: VMBUGONFOLIO(!foliotestlocked(folio)) [ 9849.452474] ------------[ cut here ]------------ [ 9849.452476] kernel BUG at mm/filemap.c:1504! [ 9849.478635] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI [ 9849.481772] CPU: 2 UID: 0 PID: 84223 Comm: fsstress Not tainted 7.0.0-rc1+ #18 PREEMPT(full) [ 9849.482881] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-9.fc43 06/1 0/2025 [ 9849.484539] RIP: 0010:foliounlock+0x85/0xa0 [ 9849.485076] Code: 89 df 31 f6 e8 1c f3 ff ff 48 8b 5d f8 c9 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 48 c7 c6 80 6c d9 a7 48 89 df e8 4b b3 10 00 <0f> 0b 48 89 df e8 21 e6 2c 00 eb 9d 0f 1f 40 00 66 66 2e 0f 1f 84 [ 9849.493818] RSP: 0018:ffff8881bb8076b0 EFLAGS: 00010246 [ 9849.495740] RAX: 0000000000000000 RBX: ffffea00070c8980 RCX: 0000000000000000 [ 9849.498678] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 9849.500559] RBP: ffff8881bb8076b8 R08: 0000000000000000 R09: 0000000000000000 [ 9849.501097] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000010782000 [ 9849.502108] R13: ffff8881935de738 R14: ffff88816110d010 R15: 0000000000001000 [ 9849.502516] FS: 00007e36cbe94740(0000) GS:ffff88824a899000(0000) knlGS:0000000000000000 [ 9849.502996] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9849.503810] CR2: 000000c0002b0000 CR3: 000000011bbf6004 CR4: 0000000000772ef0 [ 9849.504459] PKRU: 55555554 [ 9849.504626] Call Trace: [ 9849.505242] <TASK> [ 9849.505379] netfswritebegin+0x7c8/0x10a0 [ 9849.505877] ? kasancheckread+0x11/0x20 [ 9849.506384] ? pfxnetfswritebegin+0x10/0x10 [ 9849.507178] cephwritebegin+0x8c/0x1c0 [ 9849.507934] genericperformwrite+0x391/0x8f0 [ 9849.508503] ? pfxgenericperformwrite+0x10/0x10 [ 9849.509062] ? fileupdatetimeflags+0x19a/0x4b0 [ 9849.509581] ? cephgetcaps+0x63/0xf0 [ 9849.510259] ? cephgetcaps+0x63/0xf0 [ 9849.510530] cephwriteiter+0xe79/0x1ae0 [ 9849.511282] ? pfxcephwriteiter+0x10/0x10 [ 9849.511839] ? lockacquire+0x1ad/0x310 [ 9849.512334] ? ksyswrite+0xf9/0x230 [ 9849.512582] ? lockisheldtype+0xaa/0x140 [ 9849.513128] vfswrite+0x512/0x1110 [ 9849.513634] ? fgetfiles+0x33/0x350 [ 9849.513893] ? pfxvfswrite+0x10/0x10 [ 9849.514143] ? mutexlocknested+0x1b/0x30 [ 9849.514394] ksyswrite+0xf9/0x230 [ 9849.514621] ? pfxksyswrite+0x10/0x10 [ 9849.514887] ? dosyscall64+0x25e/0x1520 [ 9849.515122] ? kasancheckread+0x11/0x20 [ 9849.515366] ? tracehardirqsonprepare+0x178/0x1c0 [ 9849.515655] x64syswrite+0x72/0xd0 [ 9849.515885] ? tracehardirqson+0x24/0x1c0 [ 9849.516130] x64syscall+0x22f/0x2390 [ 9849.516341] dosyscall64+0x12b/0x1520 [ 9849.516545] ? dosyscall64+0x27c/0x1520 [ 9849.516783] ? dosyscall64+0x27c/0x1520 [ 9849.517003] ? lockrelease+0x318/0x480 [ 9849.517220] ? x64sysiogetevents+0x143/0x2d0 [ 9849.517479] ? percpurefputmany.constprop.0+0x8f/0x210 [ 9849.517779] ? entrySYSCALL64afterhwframe+0x76/0x7e [ 9849.518073] ? dosyscall64+0x25e/0x1520 [ 9849.518291] ? kasancheckread+0x11/0x20 [ 9849.518519] ? tracehardirqsonprepare+0x178/0x1c0 [ 9849.518799] ? dosyscall64+0x27c/0x1520 [ 9 ---truncated---

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

powerpc/hv-gpci: fix preempt count leak in sysfs show paths

Four sysfs show() callbacks in hv-gpci take getcpuvar(hvgpcireqb) (which calls preemptdisable()) but only call the matching putcpuvar() on the error path under the 'out:' label. Every successful read leaks one preemptdisable():

processorbustopologyshow() processorconfigshow() affinitydomainviavirtualprocessorshow() affinitydomainviadomainshow()

(affinitydomainviapartitionshow() was already correct.)

On a CONFIGPREEMPT=y kernel, repeated reads raise preemptcount and eventually return to userspace with preemption still disabled. The next user-mode page fault then hits faulthandlerdisabled() == 1, gets forced to SIGSEGV, and the resulting coredump trips 'BUG: scheduling while atomic' in callusermodehelperexec -> waitforcompletionstate -> schedule:

BUG: scheduling while atomic: <task>/<pid>/0x00000004 ... schedulebug+0x6c/0x90 schedule+0x58c/0x13a0 schedule+0x48/0x1a0 scheduletimeout+0x104/0x170 waitforcompletionstate+0x16c/0x330 callusermodehelperexec+0x254/0x2d0 vfscoredump+0x1050/0x2590 getsignal+0xb9c/0xc80 donotifyresume+0xf8/0x470

Add an outsuccess label that calls putcpuvar() before returning the byte count, mirroring affinitydomainviapartitionshow().

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

nvme: fix bio leak on mapping failure

The local bio is always NULL, so we'd leak the bio if the integrity mapping failed. Just get it directly from the request.

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

netfilter: xtables: allocate hook ops while under mutex

arp/ip(6)tregistertable() add the table to the per-netns list via xtregistertable() before allocating the per-netns hook ops copy via kmemduparray(). This leaves a window where the table is visible in the list with ops=NULL.

If the pernet exit happens runs concurrently the preexit callback finds the table via xtfindtable() and passes the NULL ops pointer to nfunregisternethooks(), causing a NULL dereference:

general protection fault in nfunregisternethooks+0xbc/0x150 RIP: nfunregisternethooks (net/netfilter/core.c:613) Call Trace: iptunregistertablepreexit iptablemanglenetpreexit opspreexitlist cleanupnet

Fix by moving the ops allocation into the xtables core so the table is never in the list without valid ops. Also ensure the table is no longer processing packets before its torn down on error unwind. nfregisternethooks might have published at least one hook; call synchronizercu() if there was an error.

audit log register message gets deferred until all operations have passed, this avoids need to emit another ureg message in case of error unwinding.

Based on earlier patch by Tristan Madani.

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

hwmon: (pmbus/adm1266) reject short block-read responses in the GPIO accessors

adm1266gpioget() and adm1266gpiogetmultiple() both compose the pin-status word as

pinsstatus = readbuf[0] + (readbuf[1] << 8);

right after i2csmbusreadblockdata(), guarding only against an error return. A well-behaved device returns 2 bytes for GPIOSTATUS/PDIOSTATUS, but the helper happily reports a 0- or 1-byte response too. If the device returns 0 bytes, both readbuf slots are uninitialized stack memory; if it returns 1 byte, readbuf[1] is.

The composed value then flows through setbit() into the caller's bits in adm1266gpiogetmultiple(), or into the return value of adm1266gpioget(), and ends up in userspace via gpiolib (sysfs and the char-dev ioctls). That leaks a few bits of kernel stack per request on any device whose firmware glitch, bus error, or hostile slave produces a short block-read response.

Add the missing length check to both call sites and surface a short response as -EIO.

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

netfs: Fix folio->private handling in netfsperformwrite()

Under some circumstances, netfsperformwrite() doesn't correctly manipulate folio->private between NULL, NETFSFOLIOCOPYTOCACHE, pointing to a group and pointing to a netfsfolio struct, leading to potential multiple attachments of private data with associated folio ref leaks and also leaks of netfsfolio structs or netfsgroup refs.

Fix this by consolidating the place at which a folio is marked uptodate in one place and having that look at what's attached to folio->private and decide how to clean it up and then set the new group. Also, the content shouldn't be flushed if group is NULL, even if a group is specified in the netfsgroup parameter, as that would be the case for a new folio. A filesystem should always specify netfsgroup or never specify netfsgroup.

The Sashiko auto-review tool noted that it was theoretically possible that the fpos >= ctx->zeropoint section might leak if it modified a streaming write folio. This is unlikely, but with a network filesystem, third party changes can happen. It also pointed out that netfssetgroup() would leak if called multiple times on the same folio from the "whole folio modify section".

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

netfs: Fix leak of request in netfswritebegin() error handling

Fix netfswritebegin() to not leak our ref on the request in the event that we get an error from netfswaitforread().

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

netfs: Fix potential deadlock in write-through mode

Fix netfsadvancewritethrough() to always unlock the supplied folio and to mark it dirty if it isn't yet written to the end. Unfortunately, it can't be marked for writeback until the folio is done with as that may cause a deadlock against mmapped reads and writes.

Even though it has been marked dirty, premature writeback can't occur as the caller is holding both inode->irwsem (which will prevent concurrent truncation, fallocation, DIO and other writes) and ictx->wblock (which will cause flushing to wait and writeback to skip or wait).

Note that this may be easier to deal with once the queuing of folios is split from the generation of subrequests.

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

drm/msm/adreno: fix userspace-triggered crash on a2xx-a4xx

Before a5xx Adreno driver will not try fetching UBWC params (because those generations didn't support UBWC anyway), however it's still possible to query UBWC-related params from the userspace, triggering possible NULL pointer dereference. Check for UBWC config in adrenogetparam() and return sane defaults if there is none.

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

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

block: bio-integrity: Fix null-ptr-deref in biointegritymapuser()

pinuserpagesfast() can partially succeed and return the number of pages that were actually pinned. However, the biointegritymapuser() does not handle this partial pinning. This leads to a general protection fault since bvecfrompages() dereferences an unpinned page address, which is 0.

To fix this, add a check to verify that all requested memory is pinned. If partial pinning occurs, unpin the memory and return -EFAULT.

Kernel Oops:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 UID: 0 PID: 1061 Comm: nvme-passthroug Not tainted 7.0.0-11783-g90957f9314e8-dirty #16 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 RIP: 0010:biointegritymapuser.cold+0x1b0/0x9d6

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

ksmbd: fix SID memory leak in setposixaclentriesdacl() on overflow

Commit 299f962c0b02 ("ksmbd: use checkaddoverflow() to prevent u16 DACL size overflow") added checkaddoverflow() guards that break out of the ACE-building loops in setposixaclentriesdacl() when the accumulated DACL size would wrap past 65535.

However, each iteration allocates a struct smbsid via kmallocobj() at the top of the loop and relies on the kfree(sid) call at the end of the loop body (the 'passsamesid' label in the first loop, and the explicit kfree at the tail of the second loop) to release it. The newly introduced 'break' statements bypass those kfree() calls, leaking the sid buffer every time an overflow is detected.

A malicious or malformed file with enough POSIX ACL entries to trip the overflow check will leak one or more struct smbsid allocations on every request that touches the file's DACL, providing a trivial kernel memory exhaustion vector.

Free sid before breaking out of the loops to plug the leak.

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

platform/x86: uniwill-laptop: Do not enable the charging limit even when forced

It seems that on some older models (~2020) the battery charging limit can permanently damage the battery. Prevent users from enabling this feature thru the "force" module parameter to avoid causing permanent hardware damage on such devices.

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

Bluetooth: btmtk: fix urb->setuppacket leak in error paths

The setuppacket of control urb is not freed if usbsubmiturb fails or the submitted urb is killed. Add free in these two paths.

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

erofs: fix metabuf leak in inode xattr initialization

commit bb88e8da0025 ("erofs: use meta buffers for xattr operations") converted xattr operations to use on-stack erofsbuf instances. erofsinitinodexattrs() uses such a metabuf while reading the inline xattr header and shared xattr id array.

Some error paths after erofsreadmetabuf() leave through outunlock without dropping the metabuf, so the folio reference can leak.

Consolidate the cleanup at outunlock. erofsputmetabuf() is a no-op if no folio has been acquired, and this keeps all paths after taking EROFSIBLXATTRBIT covered by a single cleanup site.

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

pdscore: fix debugfslookup dentry leak and error handling

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

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

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

dma-mapping: move dmamapresource() sanity check into debug code

dmamapresource() uses pfnvalid() to ensure the range is not RAM. However, pfnvalid() only checks for availability of the memory map for a PFN but it does not ensure that the PFN is actually backed by RAM. On ARM64 with SPARSEMEM (128MB section granularity), MMIO addresses that share a section with RAM will falsely trigger the WARNONONCE and cause dmamapresource() to return DMAMAPPINGERROR.

This causes a WARNING on Raspberry Pi 4 during spibcm2835 probe because the SPI FIFO register (0xfe204004) falls in the same sparsemem section as the end of RAM (0xf8000000-0xfbffffff), both in section 31 (0xf8000000-0xffffffff).

Move the sanity check from dmamapresource() into debugdmamapphys() and replace the unreliable pfnvalid() with pfnvalid() && !PageReserved(), which correctly identifies actual usable RAM without false positives for MMIO regions that happen to have struct pages.

Since dmamapresource() is dmamapphys(DMAATTRMMIO), the check applies equally to both APIs. Any non-reserved page represents kernel memory to a sufficient degree that using DMAATTRMMIO on it is almost certainly wrong and risks breaking coherency on non-coherent platforms. ZONEDEVICE pages used for PCI P2P DMA (MEMORYDEVICEPCIP2PDMA) have PageReserved set, so they will not trigger a false positive.

The check no longer blocks the mapping and uses errprintk() to integrate with dma-debug filtering.

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

drm/msm/adreno: Fix a reference leak in a6xxgpuinit()

In a6xxgpuinit(), node is obtained via ofparsephandle(). While there was a manual ofnodeput() at the end of the common path, several early error returns would bypass this call, resulting in a reference leak. Fix this by using the free(devicenode) cleanup handler to release the reference when the variable goes out of scope.

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

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

wifi: ath11k: fix error path leaks in some WMI WOW calls

Fix two instances where we used to directly return the result of ath11kwmicmdsend(...). Because we did not check the return value, we also did not free the skb in the error path.

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

netfs: Fix partial invalidation of streaming-write folio

In netfsinvalidatefolio(), if the region of a partial invalidation overlaps the front (but not all) of a dirty write cached in a streaming write page (dirty, but not uptodate, with the dirty region tracked by a netfsfolio struct), the function modifies the dirty region - but incorrectly as it moves the region forward by setting the start to the start, not the end, of the invalidation region.

Fix this by setting finfo->dirtyoffset to the end of the invalidation region (iend).

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

netfs: Fix zeropoint update where isize > remoteisize

Fix the update of the zero point[] by netfsreleasefolio() when there is uncommitted data in the pagecache beyond the folio being released but the on-server EOF is in this folio (ie. isize > remoteisize). The update needs to limit zeropoint to remoteisize, not isize as isize is a local phenomenon reflecting updates made locally to the pagecache, not stuff written to the server. remoteisize tracks the server's isize.

[] The zero point is the file position from which we can assume that the server will just return zeros, so we can avoid generating reads.

Note that netfsinvalidatefolio() probably doesn't need fixing as zeropoint should be updated by setattr after truncation or fallocate.

Found with:

fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops

using the following as junk.fsxops:

truncate 0x0 0x1bbae 0x82864 write 0x3ef2e 0xf9c8 0x1bbae write 0x67e05 0xcb5a 0x4e8f6 mapread 0x57781 0x85b6 0x7495f copyrange 0x5d3d 0x10329 0x54fac 0x7495f write 0x64710 0x1c2b 0x7495f mapread 0x64000 0x1000 0x7495f

on cifs with the default cache option.

It shows read-gaps on folio 0x64 failing with a short read (ie. it hits EOF) if the FMODEREAD check is commented out in netfsperformwrite():

if (//(file->fmode & FMODEREAD) || netfsiscacheenabled(ctx)) {

and no fscache. This was initially found with the generic/522 xfstest.

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

media: rc: igorplugusb: fix control request setup packet

Commit eac69475b01f ("media: rc: igorplugusb: heed coherency rules") changed the control request storage from an embedded struct to an allocated pointer so it can obey DMA coherency rules.

However, the driver still passes &ir->request to usbfillcontrolurb(). That points the URB setup packet at the pointer field itself rather than at the allocated struct usbctrlrequest.

USB core then interprets pointer bytes as the setup packet. This can produce an invalid bRequestType and trigger the control direction warning reported by syzbot:

usb 2-1: BOGUS control dir, pipe 80003580 doesn't match bRequestType 0

Pass ir->request itself as the setup packet.

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

gpio: rockchip: teardown bugs and resource leaks

Address several teardown issues and resource leaks in the driver's remove path and error handling:

1. Debounce clock reference leak: The debounce clock (bank->dbclk) is obtained using ofclkget() which increments the clock's reference count, but clkput() is never called. Register a devm action to cleanly release it on unbind. Note that ofclkget(..., 1) remains necessary over devmclkget() because the DT binding does not define clock-names, precluding name-based lookup.

2. Unregistered chained IRQ handler: The chained IRQ handler is not disconnected in remove(). If a stray interrupt fires after the driver is removed, the kernel attempts to execute a stale handler, leading to a panic. Fix this by clearing the handler in remove().

3. IRQ domain leak: The linear IRQ domain and its generic chips are allocated manually during probe but never removed. Remove the IRQ domain during driver teardown to free the associated generic chips and mappings.

[Bartosz: don't emit an error message on devres allocation failure]