In the Linux kernel, the following vulnerability has been resolved:
net: fix memory leak in skbsegmentlist for GRO packets
When skbsegmentlist() is called during packet forwarding, it handles packets that were aggregated by the GRO engine.
Historically, the segmentation logic in skbsegmentlist assumes that individual segments are split from a parent SKB and may need to carry their own socket memory accounting. Accordingly, the code transfers truesize from the parent to the newly created segments.
Prior to commit ed4cccef64c1 ("gro: fix ownership transfer"), this truesize subtraction in skbsegmentlist() was valid because fragments still carry a reference to the original socket.
However, commit ed4cccef64c1 ("gro: fix ownership transfer") changed this behavior by ensuring that fraglist entries are explicitly orphaned (skb->sk = NULL) to prevent illegal orphaning later in the stack. This change meant that the entire socket memory charge remained with the head SKB, but the corresponding accounting logic in skbsegmentlist() was never updated.
As a result, the current code unconditionally adds each fragment's truesize to deltatruesize and subtracts it from the parent SKB. Since the fragments are no longer charged to the socket, this subtraction results in an effective under-count of memory when the head is freed. This causes skwmemalloc to remain non-zero, preventing socket destruction and leading to a persistent memory leak.
The leak can be observed via KMEMLEAK when tearing down the networking environment:
unreferenced object 0xffff8881e6eb9100 (size 2048): comm "ping", pid 6720, jiffies 4295492526 backtrace: kmemcacheallocnoprof+0x5c6/0x800 skprotalloc+0x5b/0x220 skalloc+0x35/0xa00 inet6create.part.0+0x303/0x10d0 sockcreate+0x248/0x640 syssocket+0x11b/0x1d0
Since skbsegmentlist() is exclusively used for SKBGSOFRAGLIST packets constructed by GRO, the truesize adjustment is removed.
The call to skbreleaseheadstate() must be preserved. As documented in commit cf673ed0e057 ("net: fix fraglist segmentation reference count leak"), it is still required to correctly drop references to SKB extensions that may be overwritten during copyskbheader().
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: ffs: Initialize epfile->in early to fix endpoint direction checks
When parsing endpoint descriptors, ffsdatagotdescs() generates the epsaddrmap which contains the endpoint direction. However, epfile->in was previously only populated in ffsfuncepsenable() which executes upon USB host connection. As a result, early userspace ioctls like FUNCTIONFSDMABUFATTACH that run before the host connects would see epfile->in as 0, leading to incorrect DMA directions.
By moving the initialization to ffsepfilescreate(), epfile->in is accurate before userspace opens the endpoint files.
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: ffs: Fix DMA fence leak
In ffsdmabuftransfer(), a ffsdmafence object is kmalloc'd, with the underlying dmafence later initialized by dmafenceinit(), which sets its kref counter to 1. Then, dmaresvaddfence() gets a second reference, and a pointer to the ffsdmafence is passed as the usbrequest's "context" field.
The dma-resv mechanism will manage the second reference, but the first reference is never properly released; the ffsdmabufcleanup() function decreases the reference count, but only to balance with the reference grab in ffsdmabufsignaldone().
The code will then slowly leak memory as more ffsdmafence objects are created without being ever freed.
Address this issue by transferring ownership of the fence to the DMA reservation object, by calling dmafenceput() right after dmaresvaddfence(). The ffsdmafence then gets properly discarded after being signalled.
crypto: starfive - Do not free stack buffer
Bluetooth: HCI: Remove HCIAMP support
afunix: Set gcinprogress to true in unixgc().
In the Linux kernel, the following vulnerability has been resolved:
cppccpufreq: Fix possible null pointer dereference
cppccpufreqgetrate() and hisicppccpufreqgetrate() can be called from different places with various parameters. So cpufreqcpuget() can return null as 'policy' in some circumstances. Fix this bug by adding null return check.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix null pointer dereference in compareguidkey()
sessionfdcheck() walks the per-inode moplist during durable-handle session teardown and sets op->conn = NULL for every opinfo whose conn matched the closing session's connection. The matching opinfo, however, stays linked in its per-ClientGuid leasetablelist entry's lb->leaselist because destroyleasetable() only runs on full TCP-connection teardown, not on SESSIONLOGOFF.
If the same TCP connection then negotiates a fresh session with the same ClientGuid (ClientGuid is bound to NEGOTIATE, not the session, and is unchanged across LOGOFF + SETUP) and issues a SMB2 CREATE with a lease context on a different inode, findsameleasekey() walks lb->leaselist, reaches the stale opinfo, and calls compareguidkey(), which unconditionally dereferences opinfo->conn->ClientGUID. The conn pointer is NULL and the kernel panics.
Reproducer requires only a successful SMB2 SESSIONSETUP and a share configured with 'durable handles = yes'. KASAN report on mainline 70390501d194:
general protection fault, probably for non-canonical address 0xdffffc0000000069: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000348-0x000000000000034f] Workqueue: ksmbd-io handleksmbdwork RIP: 0010:bcmp+0x5b/0x230 Call Trace: compareguidkey+0x4b/0xd0 findsameleasekey+0x324/0x690 smb2open+0x6aea/0x8e60 handleksmbdwork+0x796/0xee0 ...
Faulting address 0x348 is the offset of ClientGUID within struct ksmbdconn, confirming opinfo->conn was NULL.
Read opinfo->conn once and bail out if it has been cleared by a concurrent sessionfdcheck(). A half-detached opinfo cannot be the owner of an active lease, so returning 0 is the correct match result.
In the Linux kernel, the following vulnerability has been resolved:
fuse: clear intrentry in fuseresend and fuseremovependingreq
When fuseresend() moves a request from fpq->processing back to fiq->pending, it sets FRPENDING and clears FRSENT but does not remove the requests intrentry from fiq->interrupts. If the request had FRINTERRUPTED set from a prior signal, intrentry remains dangling on fiq->interrupts. When the requesting task then receives a fatal signal, fuseremovependingreq() sees FRPENDING=1, removes the request from fiq->pending and frees it via the refcount path, also without cleaning intrentry. The stale intrentry causes use-after-free when fusereadinterrupt() iterates fiq->interrupts: - listdelinit(&req->intrentry) -> UAF write on freed slab - req->in.h.unique -> UAF read, data leaked to userspace
Remove intrentry from fiq->interrupts in fuseresend() for interrupted requests before they are placed back on fiq->pending.
Add a WARNON if the intrentry is not empty on request destruction.
In the Linux kernel, the following vulnerability has been resolved:
kernel/fork: clear PFBLOCKTS in copyprocess()
PFBLOCKTS is only set in blktimegetns() when current->plug is non-NULL, and blkfinishplug() clears it via blkflushplug() before NULLing the plug pointer. copyprocess() breaks the invariant by inheriting PFBLOCKTS from the parent while resetting the child's plug to NULL.
Clear PFBLOCKTS alongside that assignment so callers can rely on "PFBLOCKTS set implies current->plug != NULL" and dereference current->plug unguarded.
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ti-ads1298: add bounds check to pgasettings index
ads1298pgasettings has 7 elements but ADS1298MASKCHPGA can yield values 0-7. If it yields a value >= 7, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range.
Note that the remaining value b111 is reserved so should not be seen in a correctly functioning system.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: ioam: refresh hdr pointer before ioam6event()
Reported by Sashiko:
In ipv6hopioam(), the hdr pointer is initialized to point into the skb's linear data buffer. Later, the code calls skbensurewritable(), which might reallocate the buffer:
if (skbensurewritable(skb, optoff + 2 + hdr->optlen)) goto drop;
/ Trace pointer may have changed / trace = (struct ioam6tracehdr )(skbnetworkheader(skb) + optoff + sizeof(hdr));
ioam6filltracedata(skb, ns, trace, true);
ioam6event(IOAM6EVENTTRACE, devnet(skb->dev), GFPATOMIC, (void )trace, hdr->optlen - 2);
If the skb is cloned or lacks sufficient linear headroom, skbensurewritable() will invoke pskbexpandhead(), which reallocates the skb's data buffer and frees the old one, invalidating pointers to it. While the code recalculates the trace pointer immediately after the call to skbensurewritable(), it fails to recalculate the hdr pointer.
This patch fixes the above by recalculating the hdr pointer before passing hdr->optlen to ioam6event(), so that we avoid any UaF.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate payload size in ipc response
If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc response to ksmbd kernel server. ksmbd should validate payload size of ipc response from ksmbd.mountd to avoid memory overrun or slab-out-of-bounds. This patch validate 3 ipc response that has payload.
In the Linux kernel, the following vulnerability has been resolved:
x86/ftrace: Relocate %rip-relative percpu refs in dynamic trampolines
With CONFIGCALLDEPTHTRACKING enabled on an x86 retbleed-affected platform (eg: Skylake), with retbleed=stuff, registering a dynamic ftrace trampoline crashes on the first call into the traced function:
BUG: unable to handle page fault for address: ffff88817ae18880 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 4b53067 P4D 4b53067 PUD 0 Oops: Oops: 0002 [#1] SMP PTI CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 <65> 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89 Call Trace: <TASK> ? findheldlock ? excpagefault ? lockrelease ? x64sysclocknanosleep ? lockdephardirqsonprepare ? tracehardirqson x64sysclocknanosleep dosyscall64 ? excpagefault ? calldepthreturnthunk entrySYSCALL64afterhwframe ... Kernel panic - not syncing: Fatal exception
This small reproducer allows to easily trigger the crash:
# echo 'p x64sysclocknanosleep' > /sys/kernel/tracing/kprobeevents # echo 1 > /sys/kernel/tracing/events/kprobes/px64sysclocknanosleep0/enable # usleep 1
Monitoring the crash under GDB points to the exact instruction in charge of incrementing the call depth:
sarq $5, %gs:x86calldepth(%rip)
This instruction matches the one inserted by the ftraceregscaller from ftrace64.S. This emitted code was likely working fine until the introduction of
59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PERCPUVAR()"):
it has made the call depth accounting addressing relative to $rip, instead of being based on an absolute address.
As this code exact location depends on where the trampoline lives in memory, the corresponding displacement needs to be adjusted at runtime to actually correctly find the per-cpu x86calldepth value, otherwise the targeted address is wrong, leading to the page fault seen above.
Fix the %rip-relative displacement of the copied CALLDEPTHACCOUNT instruction (from ftraceregscaller) by calling textpokeapplyrelocation(), as it is done for example by the x86 BPF JIT compiler through x86calldepthemitaccounting(). This corrects both CALLDEPTHACCOUNT slots, in ftracecaller and ftraceregscaller.
[ bp: Massage. ]
In the Linux kernel, the following vulnerability has been resolved:
lib/testhmm.c: handle srcpfns and dstpfns allocation failure
The kcalloc() in dmirrordeviceevictchunk() will return null if the physical memory has run out. As a result, if srcpfns or dstpfns is dereferenced, the null pointer dereference bug will happen.
Moreover, the device is going away. If the kcalloc() fails, the pages mapping a chunk could not be evicted. So add a GFPNOFAIL flag in kcalloc().
Finally, as there is no need to have physically contiguous memory, Switch kcalloc() to kvcalloc() in order to avoid failing allocations.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: consume only present negotiated TTLM maps
ieee80211tidtolinkmapsizeok() validates negotiated TTLM elements against the number of link-map entries indicated by linkmappresence. ieee80211parsenegttlm() must consume the same layout.
The parser advanced its cursor for every TID, including TIDs whose presence bit is clear and therefore have no map bytes in the element. A sparse map can then make a later present TID read past the validated element.
The bad bytes land in negttlm->{up,down}link[tid] but are gated by validlinks before being applied to driver state, so a peer cannot turn the read into a policy change. Under KUnit + KASAN with an exact-sized element allocation the OOB read is reported as a slab-out-of-bounds; whether the same trigger fires under the production RX path depends on surrounding allocator state.
Advance the cursor only when the current TID has a map present.
In the Linux kernel, the following vulnerability has been resolved:
timers/migration: Fix livelock in tmigrhandleremoteup()
tmigrhandleremotecpu() skips timerexpireremote() when cpu == smpprocessorid(), assuming the local softirq path already handled this CPU's timers.
This assumption is wrong because jiffies can advance after the handling of the CPU's global timers in runtimerbase(BASEGLOBAL) and before tmigrhandleremote() evaluates the expiry times.
As a consequence a timer which expires after the CPU local timer wheel advanced and becomes expired in the remote handling is ignored and the callback is never invoked and removed from the timer wheel.
What's worse is that fetchnexttimerinterruptremote() keeps reporting it as expired, and the event is re-queued with expires == now on each iteration. The goto-again loop spins indefinitely.
Fix this by calling timerexpireremote() unconditionally. That's minimal overhead for the common case as runtimerbase() returns immediately if there is nothing to expire in the local wheel.
[ tglx: Amend change log and add a comment ]
In the Linux kernel, the following vulnerability has been resolved:
bpf: Validate nodeid in arenaallocpages()
arenaallocpages() accepts a plain int nodeid and forwards it through the entire allocation chain without any bounds checking.
Validate nodeid before passing it down the allocation chain in arenaallocpages().
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smb2open during durable reconnect
In smb2open, the call to ksmbdputdurablefd(fp) drops the reference to the durable file descriptor early during the durable reconnect process. If an error occurs subsequently (eg, ksmbdiovpinrsp fails) or a scavenger accesses the file, it leads to a use-after-free when accessing fp properties (eg fp->createtime).
Move the single put to the end of the function below errout2 so fp stays valid until smb2open returns.
In the Linux kernel, the following vulnerability has been resolved:
iio: pressure: mprls0025pa: fix spitransfer struct initialisation
Make sure that the spitransfer struct is zeroed out before use.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix out-of-bounds stream encoder index v3
engid can be negative and that streamencregs[] can be indexed out of bounds.
engid is used directly as an index into streamencregs[], which has only 5 entries. When engid is 5 (ENGINEIDDIGF) or negative, this can access memory past the end of the array.
Add a bounds check using ARRAYSIZE() before using engid as an index. The unsigned cast also rejects negative values.
This avoids out-of-bounds access.
Fixes the below smatch error: dcnresource.c: streamencodercreate() may index streamencregs[engid] out of bounds (size 5).
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn351/dcn351resource.c 1246 static struct streamencoder dcn35streamencodercreate( 1247 enum engineid engid, 1248 struct dccontext ctx) 1249 {
...
1255 1256 / Mapping of VPG, AFMT, DME register blocks to DIO block instance / 1257 if (engid <= ENGINEIDDIGF) {
ENGINEIDDIGF is 5. should <= be <?
Unrelated but, ugh, why is Smatch saying that "engid" can be negative? endid is type signed long, but there are checks in the caller which prevent it from being negative.
1258 vpginst = engid; 1259 afmtinst = engid; 1260 } else 1261 return NULL; 1262
...
1281 1282 dcn35diostreamencoderconstruct(enc1, ctx, ctx->dcbios, 1283 engid, vpg, afmt, --> 1284 &streamencregs[engid], ^^^^^^^^^^^^^^^^^^^^^^^ This streamencregs[] array has 5 elements so we are one element beyond the end of the array.
...
1287 return &enc1->base; 1288 }
v2: use explicit bounds check as suggested by Roman/Dan; avoid unsigned int cast
v3: The compiler already knows how to compare the two values, so the cast (int) is not needed. (Roman)
In the Linux kernel, the following vulnerability has been resolved:
smb/client: fix out-of-bounds read in smb2compoundop()
If a server sends a truncated response but a large OutputBufferLength, and terminates the EA list early, checkwsleas() returns success without validating that the entire OutputBufferLength fits within iovlen.
Then smb2compoundop() does: memcpy(idata->wsl.eas, data[0], size[0]);
Where size[0] is OutputBufferLength. If iovlen is smaller than size[0], memcpy can read beyond the end of the rspiov allocation and leak adjacent kernel heap memory.
In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc: take vmappurgelock in shrinker
decayvapoolnode() can be invoked concurrently from two paths: purgevmaparealazy() when pools are being purged, and the shrinker via vmapnodeshrinkscan().
However, decayvapoolnode() is not safe to run concurrently, and the shrinker path currently lacks serialization, leading to races and possible leaks.
Protect decayvapoolnode() by taking vmappurgelock in the shrinker path to ensure serialization with purge users.
In the Linux kernel, the following vulnerability has been resolved:
net: ks8851: Reinstate disabling of BHs around IRQ handler
If the driver executes ks8851irq() AND a TX packet has been sent, then the driver enables TX queue via netifwakequeue() which schedules TX softirq to queue packets for this device.
If CONFIGPREEMPTRT=y is set AND a packet has also been received by the MAC, then ks8851rxpkts() calls netdevallocskbipalign() to allocate SKBs for the received packets. If netdevallocskbipalign() is called with BH enabled, then localbhenable() at the end of netdevallocskbipalign() will trigger the pending softirq processing, which may ultimately call the .xmit callback ks8851startxmitpar(). The ks8851startxmitpar() will try to lock struct ks8851netpar .lock spinlock, which is already locked by ks8851irq() from which ks8851startxmitpar() was called. This leads to a deadlock, which is reported by the kernel, including a trace listed below.
If CONFIGPREEMPTRT is not set, then since commit 0913ec336a6c0 ("net: ks8851: Fix deadlock with the SPI chip variant") the deadlock can also be triggered without received packet in the RX FIFO. The pending softirqs will be processed on return from spinunlockbh(&ks->statelock) in ks8851irq(), which triggers the deadlock as well.
Fix the problem by disabling BH around critical sections, including the IRQ handler, thus preventing the nettxaction() softirq from triggering during these critical sections. The nettxaction() softirq is triggered once BH are re-enabled and at the end of the IRQ handler, once all the other IRQ handler actions have been completed.
schedule from schedulertlock+0x1c/0x34 schedulertlock from rtlockslowlocklocked+0x548/0x904 rtlockslowlocklocked from rtspinlock+0x60/0x9c rtspinlock from ks8851startxmitpar+0x74/0x1a8 ks8851startxmitpar from netdevstartxmit+0x20/0x44 netdevstartxmit from devhardstartxmit+0xd0/0x188 devhardstartxmit from schdirectxmit+0xb8/0x25c schdirectxmit from qdiscrun+0x1f8/0x4ec qdiscrun from qdiscrun+0x1c/0x28 qdiscrun from nettxaction+0x1f0/0x268 nettxaction from handlesoftirqs+0x1a4/0x270 handlesoftirqs from localbhenableip+0xcc/0xe0 localbhenableip from allocskb+0xd8/0x128 allocskb from netdevallocskb+0x3c/0x19c netdevallocskb from ks8851irq+0x388/0x4d4 ks8851irq from irqthreadfn+0x24/0x64 irqthreadfn from irqthread+0x178/0x28c irqthread from kthread+0x12c/0x138 kthread from retfromfork+0x14/0x28
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Completely fix fcport double free
In qla24xxelsdcmdiocb() sp->free is set to qla2x00elsdcmdspfree(). When an error happens, this function is called by qla2x00sprelease(), when krefput() releases the first and the last reference.
qla2x00elsdcmdspfree() frees fcport by calling qla2x00freefcport(). Doing it one more time after krefput() is a bad idea.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smblazyparentleasebreakclose()
opinfo pointer obtained via rcudereference(fp->fopinfo) is being accessed after rcureadunlock() has been called. This creates a race condition where the memory could be freed by a concurrent writer between the unlock and the subsequent pointer dereferences (opinfo->islease, etc.), leading to a use-after-free.
In the Linux kernel, the following vulnerability has been resolved:
net: nexthop: fix percpu use-after-free in removenhgrpentry
When removing a nexthop from a group, removenhgrpentry() publishes the new group via rcuassignpointer() then immediately frees the removed entry's percpu stats with freepercpu(). However, the synchronizenet() grace period in the caller removenexthopfromgroups() runs after the free. RCU readers that entered before the publish still see the old group and can dereference the freed stats via nhgrpentrystatsinc() -> getcpuptr(nhge->stats), causing a use-after-free on percpu memory.
Fix by deferring the freepercpu() until after synchronizenet() in the caller. Removed entries are chained via nhlist onto a local deferred free list. After the grace period completes and all RCU readers have finished, the percpu stats are safely freed.
In the Linux kernel, the following vulnerability has been resolved:
nvmem: zynqmpnvmem: Fix buffer size in DMA and memcpy
Buffer size used in dma allocation and memcpy is wrong. It can lead to undersized DMA buffer access and possible memory corruption. use correct buffer size in dmaalloccoherent and memcpy.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in ksmbdclosefd() via durable scavenger
When a durable file handle survives session disconnect (TCP close without SMB2LOGOFF), sessionfdcheck() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->locklist.
Later, when the durable scavenger thread times out and calls ksmbdclosefd(NULL, fp), the lock cleanup loop did:
spinlock(&fp->conn->llistlock);
This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbdtcpdisconnect().
The root cause is asymmetric cleanup: lock entries (smblock->clist) were left dangling on the freed conn->locklist while fp->conn was nulled out.
To fix this issue properly, we need to handle the lifetime of smblock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's locklist in sessionfdcheck() - Re-add the lock to the new connection's locklist in ksmbdreopendurablefd().
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate owner of durable handle on reconnect
Currently, ksmbd does not verify if the user attempting to reconnect to a durable handle is the same user who originally opened the file. This allows any authenticated user to hijack an orphaned durable handle by predicting or brute-forcing the persistent ID.
According to MS-SMB2, the server MUST verify that the SecurityContext of the reconnect request matches the SecurityContext associated with the existing open. Add a durableowner structure to ksmbdfile to store the original opener's UID, GID, and account name. and catpure the owner information when a file handle becomes orphaned. and implementing ksmbdvfscomparedurableowner() to validate the identity of the requester during SMB2CREATE (DHnC).