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.

bpf: Reject dev-bound-only programs on other devices

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

net/sched: reject IDR error pointers when deleting actions

tcfactiondelete() drops the reference held by its lookup before calling tcfidrdeleteindex() with the saved action index. An unlocked classifier can remove that action and reserve the same IDR slot with ERRPTR(-EBUSY) in between.

tcfidrdeleteindex() only checks the lookup result for NULL. It therefore treats the reservation as a tcaction and dereferences tcfabindcnt. A hardware execution breakpoint was used to schedule the interleaving without changing the kernel source. KASAN reported this decoded trace:

BUG: KASAN: null-ptr-deref in tcaactiongd+0x5b9/0x1010 Read of size 4 at addr 0000000000000010 by task poc/150 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002 RIP: tcaactiongd+0x5c0/0x1010: archatomicread at arch/x86/include/asm/atomic.h:23 rawatomicread at include/linux/atomic/atomic-arch-fallback.h:457 atomicread at include/linux/atomic/atomic-instrumented.h:33 tcfidrdeleteindex at net/sched/actapi.c:766 tcfactiondelete at net/sched/actapi.c:1859 tcfdelnotify at net/sched/actapi.c:2014 tcaactiongd at net/sched/actapi.c:2064 R13: 0000000000000010 R15: fffffffffffffff0 Kernel panic - not syncing: Fatal exception

R15 contains ERRPTR(-EBUSY), and adding the tcfabindcnt offset produces the address in R13. With the guard applied, the same reproducer returned -ENOENT without a KASAN report or panic. Treat error pointers as absent and return -ENOENT.

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

netfilter: ip6trpfilter: reject routes without inet6dev

ip6routelookup() can return an error-free route whose rt6iidev is NULL. Lowering an external nexthop device's MTU below IPV6MINMTU tears down its inet6dev while fib6ifdown() leaves routes using nexthop objects in the FIB. An unprivileged user can construct this state with rtnetlink in a private user and network namespace, then trigger a NULL dereference through an IPv6 rpfilter lookup:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: rpfiltermt (net/ipv6/netfilter/ip6trpfilter.c:75) Call Trace: ip6tdotable (net/ipv6/netfilter/ip6tables.c:316) nfhookslow (net/netfilter/core.c:619) ipv6rcv (net/ipv6/ip6input.c:351) netifreceiveskbonecore (net/core/dev.c:6216) processbacklog (net/core/dev.c:6680) napipoll (net/core/dev.c:7739) netrxaction (net/core/dev.c:7959) handlesoftirqs (kernel/softirq.c:622) dosoftirq.part.0 (kernel/softirq.c:523) localbhenableip (kernel/softirq.c:450) devqueuexmit (net/core/dev.c:4913) packetsendmsg (net/packet/afpacket.c:3139) syssendto (net/socket.c:2252) x64syssendto (net/socket.c:2259) dosyscall64 (arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121) Kernel panic - not syncing: Fatal exception in interrupt

Reject routes without an inet6dev immediately after lookup. Such routes are not eligible for reverse-path filtering, and the check protects all later rt6iidev dereferences.

In wacomhidsetdevicemode of wacomsys.c, there is a possible out-of-bounds write due to a missing bounds check. This could lead to physical escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

IB/iser: reject a remote invalidation of an unregistered direction

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

RDMA/mad: Fix receive buffer leak when PKey enforcement fails

ibmadcompleterecv() initializes madrecvwc->rmpplist and then runs ibmadenforcesecurity() before linking recvbuf onto that list. On failure it calls ibfreerecvmad(), which only walks rmpplist and frees the ibmadprivate of every buffer found there. As the list is still empty at that point, nothing is freed at all.

The caller cannot clean up either: ibmadrecvdone() sets recv to NULL right after ibmadcompleterecv() returns, assuming the MAD layer took ownership of the buffer. Every MAD that fails the PKey check therefore leaks one ibmadprivate (about 300 bytes per IB port MAD, ~2K for OPA), and a remote node can trigger this repeatedly by sending MADs with a wrong PKey.

Link recvbuf onto rmpplist right after the list is initialized, so the error path has something to free.

IB/IPoIB: Avoid restoring OPERUP after multicast flush

dmaengine: Fix device kref underflow in dmachanput()

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

wifi: mac80211: set up the TX info early to fix failure paths

The previous commit 2c51457d930f ("wifi: mac80211: free ack status frame on TX header build failure") cleaned up the leak, but still left the code a bit messy and the failed SKB didn't get reported to userspace.

Fix this up by initialising skb->cb[] earlier, which allows using ieee80211freetxskb() and therefore reports it for the failure in ieee80211buildhdr(), and unifies the ieee80211skbresize() failure path with it.

ALSA: pcm: set timer->privatedata before registering the PCM timer

ALSA: 6fire: fix OOB write from device-reported iso length

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

seg6: set IPSKBL3SLAVE from IP6SKBL3SLAVE on IPIP decapsulation

When an SRv6 packet arrives on an interface enslaved to a VRF, vrfip6rcv() sets IP6SKBL3SLAVE in IP6CB, but decapandvalidate() has never set IPSKBL3SLAVE in IPCB. The bit stayed clear in the common case, and with CONFIGIPV6MIP6 the leftover fragmaxsize of a reassembled outer packet could even set it, with no VRF involved. Commit 44930446dde4 ("ipv6: seg6: clear IPv4 control block on IPIP decapsulation") then made the unreliable bit reliably clear.

The effect of the missing flag is visible with End.DX4 when a delivery to a local address of the node reaches the socket lookup. For example, a UDP socket bound to the enslaved ingress interface does not receive any of the decapsulated packets, while an unbound socket outside the VRF does. This contradicts Documentation/networking/vrf.rst: by default the scope of an unbound UDP or TCP socket is limited to the default VRF.

Set IPSKBL3SLAVE for IPv4 in decapandvalidate(), which already does the same for IPv6. The socket lookup then matches the decapsulated packet like any other packet received on that enslaved interface. Such a packet matches an unbound UDP or TCP socket only when udpl3mdevaccept or tcpl3mdevaccept is set.

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

net: fddi: skfp: fix NULL deref when setting the MAC address while down

skfpctlsetmacaddress() calls ResetAdapter() unconditionally, without checking netifrunning(). ResetAdapter() first calls cardstop(), which sets smc->hw.hwstate to STOPPED, and then macdrvcleartxqueue(), which walks the two transmit queues:

for (i = QUEUES; i <= QUEUEA0; i++) { queue = smc->hw.fp.tx[i] ; ... t = queue->txcurrget ;

smc->hw.fp.tx[] is only populated by inittx(), which is reached from skfpopen() through initsmt() -> initfddidriver() -> initfplus() -> initmac() -> inittx(). The private area is allocated and zeroed by allocfddidev(), so on an interface that has never been brought up both queue pointers are still NULL. The hwstate test at the top of macdrvcleartxqueue() does not catch this, because cardstop() has just set STOPPED; the function proceeds into the loop and dereferences NULL. ResetAdapter() does call initsmt() itself, but only after the queues have been cleared.

Setting the MAC address on a down interface therefore oopses:

ip link set dev fddi0 address 02:00:00:00:00:01

BUG: KASAN: null-ptr-deref in macdrvcleartxqueue+0x68/0x2c0 [skfp] Read of size 8 at addr 0000000000000010 by task ip/302 Call Trace: <TASK> macdrvcleartxqueue+0x68/0x2c0 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] ResetAdapter+0x29/0x100 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] skfpctlsetmacaddress+0x57/0x80 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] netifsetmacaddress+0x1e4/0x2c0 dosetlink+0x684/0x2680 </TASK>

Address 0x10 is the offset of txcurrget, the third pointer in struct ssmttxqueue, on 64-bit. macdrvclearrxqueue(), which ResetAdapter() calls immediately afterwards, dereferences smc->hw.fp.rx[QUEUER1] in the same way behind the same ineffective hwstate test; the transmit queue merely crashes first. Both are covered by the guard below.

Skip the adapter reset when the interface is down. devaddrset() is left unconditional, so the new address is still recorded in dev->devaddr. Nothing is lost by not resetting the adapter here: skfpopen() deliberately re-reads the factory address on every open,

readaddress(smc, NULL); ethhwaddrset(dev, smc->hw.fddicanonaddr.a);

and the comment above it states this is done to discard exactly such an address override across a close/open cycle. An address set while the interface is down could not have survived the following open even before this change, so the guard removes no working behaviour. Guarding the hardware side of ndosetmacaddress() with netifrunning() is established practice; skgesetmacaddress() has done so since commit 2eb3e621c4e0 ("skge: set mac address bonding fix").

Guarding the reset as a whole, rather than NULL-checking the queues, is also what the rest of the driver expects. After a previous open/close the queue pointers are stale but non-NULL, so there is no crash, yet ResetAdapter() goes on to call smtonline() and STIFBI() ("Enable Board Interrupts") while skfpclose() has already called freeirq() - the adapter would be brought back online with no handler installed. The only other ResetAdapter() caller is skfpinterrupt(), which by construction runs only while the device is open.

Found by automated driver testing against an emulated SysKonnect FDDI adapter under a KASAN-enabled 7.0.0 kernel. Triggering it requires CAPNETADMIN.

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

tcp: Don't call skbcloneandcharger() for close()d listener in tcpv6dorcv().

tcpv6dorcv() no longer calls skbcloneandcharger() for TCPLISTEN since commit 073d89808c06 ("net: fix data-races around sk->skforwardalloc").

However, there is still a small race window between tcpv6rcv() and tcpv6dorcv(), where concurrent close() changes TCPLISTEN to TCPCLOSE, causing skbcloneandcharger() to be called locklessly and resulting in the splat below. [0]

Let's avoid calling skbcloneandcharger() for TCPCLOSE as well.

This is fine for non-listeners because tcprcvstateprocess() drops skb for TCPCLOSE and optskb was freed immediately anyway.

[0]: sk->skforwardalloc WARNING: net/ipv4/afinet.c:162 at inetsockdestruct+0x64d/0x810 net/ipv4/afinet.c:162, CPU#1: ksoftirqd/1/28 Modules linked in: CPU: 1 UID: 0 PID: 28 Comm: ksoftirqd/1 Not tainted 7.2.0 #17 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:inetsockdestruct+0x64d/0x810 net/ipv4/afinet.c:162 Code: 3d 49 ff e9 06 fd ff ff e8 d0 5b 83 f8 90 0f 0b 90 e9 35 fe ff ff e8 c2 5b 83 f8 90 0f 0b 90 e9 c5 fe ff ff e8 b4 5b 83 f8 90 <0f> 0b 90 e9 04 ff ff ff e8 a6 5b 83 f8 90 0f 0b 90 e9 65 fe ff ff RSP: 0018:ffffc90000677bb8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880117bde80 RCX: ffffffff8957eb41 RDX: ffff88801dad5d00 RSI: ffffffff8957ec3c RDI: 0000000000000005 RBP: 00000000fffff000 R08: ffffffff8957eb41 R09: 00000000fffff000 R10: 0000000000000005 R11: 0000000000000000 R12: dffffc0000000000 R13: ffff8880117bdf10 R14: ffffffff81c08eb7 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8880d7ae5000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f93a1021138 CR3: 00000000207a9000 CR4: 0000000000350ef0 Call Trace: <TASK> skdestruct+0x82/0xae0 net/core/sock.c:2356 rcudobatch kernel/rcu/tree.c:2645 [inline] rcucore+0x59c/0x1100 kernel/rcu/tree.c:2897 handlesoftirqs+0x1e4/0x9b0 kernel/softirq.c:622 runksoftirqd kernel/softirq.c:1076 [inline] runksoftirqd+0x38/0x60 kernel/softirq.c:1068 smpbootthreadfn+0x458/0xc80 kernel/smpboot.c:160 kthread+0x396/0x4a0 kernel/kthread.c:436 retfromfork+0x8e0/0xe40 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>

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

tcp: do not let tcprmem be set below 4096

We can hit a division by zero crash in tcprcvbufgrow() and tcprcvspaceadjust():

divide error: 0000 [#1] PREEMPT SMP RIP: 0010:tcprcvbufgrow+0x187/0x450 net/ipv4/tcpinput.c:939 ... grow = divu64(((u64)rcvwin << 1) (newval - oldval), oldval);

The division uses oldval = tp->rcvqspace.space as divisor. When tp->rcvqspace.space is zero, this leads to a divide-by-zero exception.

tp->rcvqspace.space is initialized in tcpinitbufferspace(): tp->rcvqspace.space = min3(tp->rcvssthresh, tp->rcvwnd, (u32)TCPINITCWND tp->advmss);

If tcprmem[1] is configured to very small values (such as 1), sk->skrcvbuf is initialized to 1. Then tcpfullspace(sk), which computes (sk->skrcvbuf scalingratio) >> 8, truncates to 0. This sets tp->windowclamp = 0, tp->rcvssthresh = 0, and tp->rcvqspace.space = 0. Later, when data arrives and DRS is invoked, tcprcvbufgrow() divides by oldval == 0.

Back in 2015, commit b1cb59cf2efe ("net: sysctlnetcore: check SNDBUF and RCVBUF for min length") ensured that net.core.rmemdefault and net.core.rmemmax cannot be set below SOCKMINRCVBUF. Similarly, SORCVBUF setsockopt enforces maxt(int, val 2, SOCKMINRCVBUF).

However, net.ipv4.tcprmem still had .extra1 = SYSCTLONE, allowing arbitrarily small values.

Because SOCKMINRCVBUF depends on sizeof(struct skbuff) and cacheline alignment, its value varies across architectures and configuration options. Using a fixed constant of 4096 ensures a predictable, architecture- independent lower bound that is safely above SOCKMINRCVBUF everywhere and matches the documented 4K default.

Fix this by setting tcprmem.extra1 to 4096 and updating the documentation.

ata: libahci: clear PxCLBU and PxFBU for AHCIHFLAG32BITONLY

Bluetooth: hcicodec: validate vendor codec count length

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

net: wwan: mhiwwanmbim: guard against a cyclic NDP chain

The NDP traversal in mhimbimrx() only stops when wNextNdpIndex is zero. Nothing requires the offsets to advance, so a modem that points an NDP at itself, or at an earlier NDP, keeps the loop spinning forever on one CPU.

Break out when the next NDP offset is not larger than the current one.

Verified in a QEMU guest with a fault injector feeding the driver's receive callback an NTB whose single NDP points at itself: the unpatched driver spins in mhimbimrx() with one CPU pinned at 100% and the thread never returns. With this check the loop terminates within one iteration.

Changes in v2: move the non-increasing check to the wNextNdpIndex retrieval site, as suggested by Loic Poulain, instead of tracking the previous offset in a separate variable.

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

memstick: msblock: destroy ioqueue workqueue on removal

msbinitdisk() creates the per-card ordered workqueue msb->ioqueue with allocorderedworkqueue(). It is torn down with destroyworkqueue() only on the init error path; msbremove() never destroys it. msbstop() merely flushes the queue, and neither msbdataclear() nor putdisk() free it. As a result every card insert/remove cycle leaks the workqueue and its kworker, exhausting kernel memory over repeated cycles.

Destroy the workqueue in msbremove() after the disk has been removed and the queue drained.

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

Input: evdev - zero absinfo before partial copy in EVIOCSABS

The EVIOCSABS handler copies at most the user supplied ioctl size into an uninitialized on-stack struct inputabsinfo:

if (copyfromuser(&abs, p, mint(sizet, size, sizeof(struct inputabsinfo))))

The size comes from IOCSIZE() of the ioctl command and is therefore fully controlled by userspace. A short size leaves the trailing part of the structure holding whatever was on the kernel stack, and the whole structure is then stored into the device:

dev->absinfo[t] = abs;

EVIOCGABS hands that back to userspace, disclosing the stale stack bytes. Only the resolution field is currently cleared, which covers the legacy struct layout but not an arbitrarily short size.

Zero the structure before the copy so any part not supplied by the caller reads back as zero. The existing resolution fixup is kept, since it also handles a size that partially overlaps that field.

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

Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound

Transport drivers (such as rmii2c and rmispi) invoke rmidriversuspend() and rmidriverresume() on their child rmidev device during system power management events. However, transport drivers are fully registered and operational even if the physical RMI driver failed to bind or probe the rmidev device.

When rmidriversuspend() or rmidriverresume() is called on an unbound rmidev, devgetdrvdata() returns NULL. Calling rmidisableirq() or rmienableirq() without driver data attached causes a NULL pointer dereference and General Protection Fault when attempting to lock data->enabledmutex.

Fix this by checking if driver data is attached to rmidev in rmidriversuspend() and rmidriverresume(), exiting early if no driver data is present.

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:

wifi: mwifiex: validate scan response extents

mwifiexret80211scan() subtracts the fixed response fields and the firmware-provided BSS length from resp->size without first proving that either extent fits. A short response or oversized BSS length can therefore underflow tlvbufsize and make the TLV parser walk beyond the command response.

Compute the fixed extent from the selected normal or background scan response. Validate that the fixed fields and BSS data fit before deriving the TLV extent and entering the parser.

Memory corruption while processing IOCTL command called from user space to the kernel with invalid parameters.

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

nvdimm: pmem: keep PREFLUSH before data writes

pmemsubmitbio() records a REQPREFLUSH error, but continues to copy the bio data and can later overwrite the error with a successful REQFUA flush. That lets data writes run after a failed preflush and can complete the bio successfully despite the failed ordering barrier.

Run the REQPREFLUSH flush synchronously before touching the bio data and complete the bio with the flush error if it fails. Keep asynchronous flush chaining for REQFUA. At that point, data copy has completed and the parent bio can wait for the chained flush bio.

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:

usb: typec: ucsi: unregister debugfs entries on teardown

ucsiregister() creates per-instance debugfs entries, but ucsiunregister() keeps them around until ucsidestroy().

Drivers like ucsiglink that unregister/register the same UCSI instance across remoteproc restart then try to create an already existing debugfs directory and log:

debugfs: 'pmicglink.ucsi.0' already exists in 'ucsi'

Unregister debugfs entries as part of ucsiunregister(), and clear ucsi->debugfs after freeing it so repeated unregister paths remain safe.

drm/msm: Recover HW before retire hung submit

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

staging: rtl8723bs: fix xmitframe/xmitbuf leaks on mgnt-frame error paths

issuebeacon(), issueprobersp() and issueasocrsp() obtain a management xmitframe together with its xmitbuf from the driver's fixed-size management-TX pools via allocmgtxmitframe(). On the normal path the frame is handed to dumpmgntframe(), which transfers ownership and eventually returns both objects to their pools (the frame and, for beacons, the buf in rtl8723bsmgntxmit(); other bufs via the pending-xmitbuf/TX-completion path).

Several error/edge paths return early after a successful allocmgtxmitframe() but before dumpmgntframe(), so ownership is never transferred and neither object is freed:

- issuebeacon(): beacon larger than 512 bytes - issueprobersp(): curnetwork->ielength > MAXIESZ - issueprobersp(): kzalloc() of the SSID scratch buffer fails - issueasocrsp(): pkttype is neither ASSOCRSP nor REASSOCRSP

Because allocmgtxmitframe() removes the frame and buf from their free lists (listdelinit) without placing them on any pending list, an orphaned pair is on no list and referenced by nobody, so it is only reclaimed at driver teardown. Repeated hits progressively exhaust the management-TX pools until allocmgtxmitframe() returns NULL and the interface can no longer send beacons or probe/assoc responses.

Free the frame and buffer on these paths, matching the existing correct error handling in issueassocreq().