A race condition during TCP connection teardown can cause tcprecv() to operate on a connection that has already been released. If tcpconnsearch() returns NULL while processing a SYN packet, a NULL pointer derived from stale context data is passed to tcpbacklogisfull() and dereferenced without validation, leading to a crash.

A type confusion vulnerability in Palo Alto Networks GlobalProtect™ app on Windows enables a local user with low privileges to cause a denial of service (DoS) condition.

The GlobalProtect™ app on Linux, macOS, iOS, Android, and Chrome OS is not affected by this vulnerability.

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

smb/server: fix tree connection leak in smb2treeconnect()

See the procedure below:

smb2treeconnect ksmbdtreeconnconnect xastore(&sess->treeconns, treeconn->id, treeconn) ksmbdcounterinc(KSMBDCOUNTERTREECONNS) ksmbdsharetreeconninc(sc) ksmbdiovpinrsp // fail status.ret = KSMBDTREECONNSTATUSNOMEM // do not disconnect treeconn

Disconnect the new tree connection if ksmbdiovpinrsp() fails.

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

net: stmmac: fix dma mapping leak in stmmactsoxmit()

In stmmactsoxmit(), if the DMA mapping of an skb fragment fails, the frame is dropped but the DMA mappings already created for the linear part and for the fragments mapped before the failure are never unmapped, leaking DMA mappings.

Fix the leak by walking back over the descriptors used by the frame and releasing each of them with stmmacfreetxbuffer(). Moreover, release the descriptors with stmmacreleasetxdesc() unmapping the DMA buffers.

bpf: checkcondjmpop(): properly infer if register is null

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

bpf: zero extend the result of an arena 32-bit cmpxchg

bpfconvertctxaccesses() rewrites an atomic on an arena pointer from BPFSTX | BPFATOMIC to BPFSTX | BPFPROBEATOMIC, and it runs before bpfoptsubregzextlo32rndhi32().

That pass emits an explicit zero extension for a 32-bit cmpxchg even when bpfjitneedszext() is false. This is done because on some architectures 32-bit cmpxchg requires explicit zero extension for the dst register. E.g. on x86-64 'lock cmpxchg' does not change the %eax if comparison is successful, while BPF semantics declare that each operation on a 32-bit register zero extends it's upper half.

iscmpxchginsn() matches BPFMODE == BPFATOMIC only, so an arena cmpxchg misses said zero extension adjustment. This patch adjusts iscmpxchginsn() to match BPFPROBEATOMIC alongside BPFATOMIC.

drm/amdgpu: Fix kernel panic during driver load failure

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:

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.

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

erofs: fix metabuf leak in inode xattr initialization

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.

cpufreq: zero-initialize policy cpumask before sysfs publication

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

cachefiles: Fix error return when vfsmkdir() fails

When vfsmkdir() fails, the error code is not extracted from the returned error pointer. This causes mkdirerror to be reached with ret=0, which leads to returning ERRPTR(0) (NULL) instead of a proper error pointer.

Fix this by extracting the error code from the error pointer when vfsmkdir() fails.

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

nvme-pci: fix dma mapping leak on data setup error

We're leaking the initial DMA mapping during iteration if we fail to allocate the tracking descriptor for both PRP and SGL. Unmap the iterator directly; we can't use the existing unmap helper because it depends on the tracking descriptor being successfully allocated, so a new one for an in-use iterator is provided.

The mappings were also leaking when the driver detects an invalid biovec when mapping PRPs, so fix that too.

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

ACPI: button: Fix ACPI GPE handler leak during removal

Commit a7e23ec17fee ("ACPI: button: Install notifier for system events as well") changed the ACPI notify handler type for ACPI buttons to ACPIALLNOTIFY, but it forgot to update acpibuttonremove() to reflect that change. This leads to leaking the notify handler past driver removal, which may cause a kernel crash to occur if ACPI notify on the given device is triggered after removing the driver, and causes a subsequent probe of the given device with the same driver to fail.

Address this by updating the acpiremovenotifyhandler() call in acpibuttonremove() as appropriate.

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

power: supply: max77705: Free allocated workqueue and fix removal order

Use devm interface for allocating workqueue to fix two bugs at the same time:

1. Driver leaks the memory on remove(), because the workqueue is not destroyed.

2. Driver allocates workqueue and then registers interrupt handlers with devm interface. This means that probe error paths will not use a reversed order, but first destroy the workqueue and then, via devm release handlers, free the interrupt.

The interrupt handler schedules work on this exact workqueue, thus if interrupt is hit in this short time window - after destroying workqueue, but before devm() frees the interrupt - the schedulled work will lead to use of freed memory.

Change is not equivalent in the workqueue itself: use non-legacy API which does not set (WQLEGACY | WQMEMRECLAIM). The workqueue is used to update power supply (powersupplychanged()) status, thus there is no point to run it for memory reclaim. Note that devname() is not directly used in second argument to prevent possible unlikely parsing any "%" character in device name as format.

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

net: phonet: do not BUGON() in pnsocketautobind() on failed bind

syzbot reported a kernel BUG triggered from pnsocketsendmsg() via pnsocketautobind():

kernel BUG at net/phonet/socket.c:213! RIP: 0010:pnsocketautobind net/phonet/socket.c:213 [inline] RIP: 0010:pnsocketsendmsg+0x240/0x250 net/phonet/socket.c:421 Call Trace: socksendmsgnosec+0x112/0x150 net/socket.c:797 socksendmsg net/socket.c:812 [inline] syssendto+0x402/0x590 net/socket.c:2280 ...

pnsocketautobind() calls pnsocketbind() with port 0 and, on -EINVAL, assumes the socket was already bound and asserts that the port is non-zero:

err = pnsocketbind(sock, ..., sizeof(struct sockaddrpn)); if (err != -EINVAL) return err; BUGON(!pnport(pnsk(sock->sk)->sobject)); return 0; / socket was already bound /

However pnsocketbind() also returns -EINVAL when sk->skstate is not TCPCLOSE, even when the socket has never been bound and pnport() is still 0. In that case the BUGON() fires and panics the kernel from a user-triggerable path.

Treat the "bind returned -EINVAL but pnport() is still 0" case as a regular error and propagate -EINVAL to the caller instead of crashing. Existing callers already translate a non-zero return from pnsocketautobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here only changes behaviour from panic to a normal errno.

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

drm/amd/display: Wrap DCN32 phantom-plane allocation in DCRUNWITHPREEMPTIONENABLED

[Why] dcn32validatebandwidth() wraps dcn32internalvalidatebw() with DCFPSTART()/DCFPEND(). In x86 non-RT, DCFPSTART takes fpregslock(), which disables local softirqs.

The DML1 path through dcn32enablephantomplane() calls kvzalloc() to allocate ~335 KiB for dcplanestate. This triggers the vmalloc path, which calls BUGON(ininterrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash.

[How] Wrap the dcstatecreatephantomplane() call with the DCRUNWITHPREEMPTIONENABLED() macro to allow preemption during this memory allocation.

(cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)

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

wifi: cfg80211: enforce HE/EHT cap/oper consistency

Xiang Mei reports that mac80211 could crash if ehtcap is set but ehtoper isn't. Rather than fixing that for the individual user(s), enforce that both HE/EHT have consistent elements.

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

ptp: ocp: fix resource freeing order

Commit a60fc3294a37 ("ptp: rework ptpclockunregister() to disable events") added a call to ptpdisableallevents() which changes the configuration of pins if they support EXTTS events. In ptpocpdetach() pins resources are freed before ptpclockunregister() and it leads to use-after-free during driver removal. Fix it by changing the order of free/unregister calls. To avoid irq handler running on the other core while ptp device unregistering, call synchronizeirq() after HW is configured to stop producing irqs and no irqs are in-flight.

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

wifi: iwlegacy: fix broadcast stations deallocation

On the error path of il4965up(), ildeallocbcaststations() clears only ILSTAUCODEACTIVE, leaving ILSTABCAST set. This causes the same broadcast stations to be deallocated again by il4965down().

This can occur when RFKILL is toggled during driver startup.

To fix clear the entire 'used' field, since we will not do any other operations on the station.

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

f2fs: fix data loss caused by incorrect use of natentry flag

Data loss can occur when fsync is performed on a newly created file (before any checkpoint has been written) concurrently with a checkpoint operation. The scenario is as follows:

create & write & fsync 'file A' write checkpoint - f2fsdosyncfile // inline inode - f2fswriteinode // inode folio is dirty - f2fswritecheckpoint - f2fsflushmergedwrites - f2fssyncnodepages - f2fsflushnatentries - f2fsfsyncnodepages // no dirty node - f2fsneedinodeblockupdate // return false SPO and lost 'file A'

f2fsflushnatentries() sets the ISCHECKPOINTED and HASLASTFSYNC flags for the natentry, but this does not mean that the checkpoint has actually completed successfully. However, f2fsneedinodeblockupdate() checks these flags and incorrectly assumes that the checkpoint has finished.

The root cause is that the semantics of ISCHECKPOINTED and HASLASTFSYNC are only guaranteed after the checkpoint write fully completes.

This patch modifies f2fsneedinodeblockupdate() to acquire the sbi->nodewrite lock before reading the natentry flags, ensuring that once ISCHECKPOINTED and HASLASTFSYNC are observed to be set, the checkpoint operation has already completed.

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

ice: fix race condition in TX timestamp ring cleanup

Fix a race condition between icefreetxtstampring() and icetxmap() that can cause a NULL pointer dereference.

icefreetxtstampring currently clears the ICETXFLAGSTXTIME flag after NULLing the tstampring. This could allow a concurrent icetxmap call on another CPU to dereference the tstampring, which could lead to a NULL pointer dereference.

CPU A:icefreetxtstampring() | CPU B:icetxmap() --------------------------------|--------------------------------- txring->tstampring = NULL | | iceistxtimecfg() -> true | tstampring = txring->tstampring | tstampring->count // NULL deref! flags &= ~ICETXFLAGSTXTIME |

Fix by: 1. Reordering icefreetxtstampring() to clear the flag before NULLing the pointer, with smpwmb() to ensure proper ordering. 2. Adding smprmb() in icetxmap() after the flag check to order the flag read before the pointer read, using READONCE() for the pointer, and adding a NULL check as a safety net. 3. Converting txring->flags from u8 to DECLAREBITMAP() and using atomic bitops (setbit(), clearbit(), testbit()) for all flag operations throughout the driver: - ICETXRINGFLAGSXDP - ICETXRINGFLAGSVLANL2TAG1 - ICETXRINGFLAGSVLANL2TAG2 - ICETXRINGFLAGSTXTIME

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

ice: fix potential NULL pointer deref in error path of icesetringparam()

icesetringparam nullifies tstampring of temporary txrings, without clearing ICETXRINGFLAGSTXTIME bit. When ICETXRINGFLAGSTXTIME is set and the subsequent icesetuptxring() call fails, a NULL pointer dereference could happen in the unwinding sequence:

icecleantxring() -> iceistxtimecfg() == true (ICETXRINGFLAGSTXTIME is set) -> icefreetxtstampring() -> icefreetstampring() -> tstampring->desc (NULL deref)

Clear ICETXRINGFLAGSTXTIME bit to avoid the potential issue.

Note that this potential issue is found by manual code review. Compile test only since unfortunately I don't have E830 devices.

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

drm/ttm: Fix ttmboswapout() infinite LRU walk on swapout failure

When ttmttswapout() fails, the current code calls ttmresourceaddbulkmove() followed by ttmresourcemovetolrutail() to restore the resource's bulkmove membership.

However, ttmresourcemovetolrutail() places the resource at the tail of the LRU list which, relative to the walk cursor's hitch node (placed immediately after the resource when it was yielded), puts the resource in front of the the hitch. The next listforeachentrycontinue() from the hitch finds the same resource again, causing an infinite loop.

Fix by deferring delbulkmove to the success path only.

On the success path, TTMTTFLAGSWAPPED has just been set by ttmttswapout() but the resource is still tracked in the bulkmove range, so ttmresourcedelbulkmove()'s !ttmresourceunevictable() guard would incorrectly skip the removal. Introduce ttmresourcedelbulkmoveunevictable() which bypasses that guard.

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

drm/ttm: Fix ttmboshrink() infinite LRU walk on backup failure

Apply the same fix as b2ed01e7ad ("drm/ttm: Fix ttmboswapout() infinite LRU walk on swapout failure") to the ttmboshrink() path.

Move delbulkmove from before the backup to after success only, using ttmresourcedelbulkmoveunevictable() since the resource is now unevictable once fully backed up.

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

pseries/papr-hvpipe: Fix race with interrupt handler

While executing ->ioctl handler or ->release handler, if an interrupt fires on the same cpu, then we can enter into a deadlock.

This patch fixes both these handlers to take spinlockirq{save|restore} versions of the lock to prevent this deadlock.

drm/amd/display: Fix dclink NULL handling in HPD init

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

pseries/papr-hvpipe: Fix null ptr deref in paprhvpipedevcreatehandle()

commit 6d3789d347a7 ("papr-hvpipe: convert paprhvpipedevcreatehandle() to FDPREPARE()"), changed the create handle to FDPREPARE(), but it caused kernel null-ptr-deref because after call to retainandnullptr(srcinfo), srcinfo is re-used for adding it to the global list.

Getting the following kernel panic in paprhvpipedevcreatehandle() when trying to add srcinfo to the list. Kernel attempted to write user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on write at 0x00000000 Faulting instruction address: 0xc0000000001b44a0 Oops: Kernel access of bad area, sig: 11 [#1] ... Call Trace: paprhvpipedevioctl+0x1f4/0x48c (unreliable) sysioctl+0x528/0x1064 systemcallexception+0x128/0x360 systemcallvectoredcommon+0x15c/0x2ec

Now, the error handling with FDPREPARE's file cleanup and free(kfree) auto cleanup is getting too convoluted. This is mainly because we need to ensure only 1 user get the srcID handle. To simplify this, we allocate prepare the srcinfo in the beginning and add it to the global list under a spinlock after checking that no duplicates exist.

This simplify the error handling where if the FDADD fails, we can simply remove the srcinfo from the list and consume any pending msg in hvpipe to be cleared, after srcinfo became visible in the global list.