A flaw was found in glib-networking. When establishing connections using Transport Layer Security (TLS) version 1.3, the client-side session cache does not limit the number of session tickets retained for a single host. A malicious server can exploit this by sending excessive session ticket messages, causing the client application to continuously consume memory. This unbounded memory growth can exhaust system memory, resulting in a Denial of Service (DoS).
In the Linux kernel, the following vulnerability has been resolved:
net/handshake: Take a long-lived file reference at submit
handshakenlacceptdoit() needs the file pointer backing req->hrsk->sksocket to survive the window between handshakereqnext() and the subsequent FDPREPARE() and getfile(). The submit-side sockhold() does not provide that. skrefcnt keeps struct sock alive, but struct socket is owned by sock->file: when the consumer fputs the last file reference, sockrelease() tears the socket down regardless of any sockhold.
Add an hrfile pointer to struct handshakereq and acquire an explicit reference on sock->file during handshakereqsubmit(). handshakecomplete() and handshakereqcancel() release the reference on the completion-bit-winning path.
The submit error path must also release the file reference, but after rhashtable insertion a concurrent handshakereqcancel() can discover the request and race the error path. Gate the error-path cleanup -- skdestruct restoration, fput, and request destruction -- with testandsetbit(HANDSHAKEFREQCOMPLETED), the same serialization handshakecomplete() and handshakereqcancel() already use. When cancel has already claimed ownership, the submit error path returns without touching the request; socket teardown handles final destruction.
The accept-side dereferences are not yet retargeted; that change comes in the next patch.
In the Linux kernel, the following vulnerability has been resolved:
tipc: destroy topsrv workqueues before closing connections
tipctopsrvstop() closed subscriber connections while the topology server's send and receive workqueues were still running. Socket callbacks and subscription events could then queue more work, and in-flight send/recv work could drop the last connection reference during the connidr walk.
That race produced several teardown failures: refcountt addition on 0 from connget() on a connection whose release was blocked on idrlock, a subsequent use-after-free in tipcconnclose(), queuework() on an already destroyed workqueue from the listener data-ready callback, and an RCU stall in tipctopsrvexitnet() while the walk spun under idrlock.
Clear srv->listener under idrlock so it acts as a shutdown flag, skip queuework() once it is NULL, destroy the workqueues to flush in-flight work, and only then close the remaining connections. Refuse tipcconnlookup() after that flag is cleared, and drop idrlock when the teardown walk finds no connection, so an in-flight subscription event cannot pin idrinuse while the walk holds the lock.
v3 supersedes the narrower in-thread diff Tung Quang Nguyen posted on 2026-09-23. It keeps his teardown order and adds the lookup refusal and the empty-idr unlock.
dcache: don't put a mountpoint on a dentry that's being removed
In the Linux kernel, the following vulnerability has been resolved:
net/packet: guard the ll header push in packetrcvspkt()
packetrcvspkt() restores the link layer header with
skbpush(skb, skb->data - skbmacheader(skb));
That subtraction is only meaningful when the device actually has a link layer header. packetrcv() and tpacketrcv() both wrap it in devhasheader(), which is also the predicate the block comment at the top of the file states the restore in terms of; packetrcvspkt() does not. commit d549699048b4 ("net/packet: fix packet receive on L3 devices without visible hard header") introduced the helper and changed the two call sites, and this one stayed behind.
A device without a visible ll header can leave skb->macheader at the 0xFFFF sentinel that allocskb() initialises it to. A CAN skb does: initcanskb() sets pkttype and ipsummed but does not reset the headers, and commit 9f10374bb024 ("can: remove private CAN skb headroom infrastructure") dropped the skbresetheader() calls that used to be there. skbmacheader() is then 0xFFFF, the length becomes a large negative number and skbpush() reports it through skbunderpanic() -- from softirq context, so it is a full system panic even with paniconoops=0:
skbuff: skbunderpanic: text:ffffffff8bd21bc1 len:-65455 put:-65471 head:... data:... tail:0x50 end:0x180 dev:can0 kernel BUG at net/core/skbuff.c:214! RIP: 0010:skbpanic+0x50/0x60 Call Trace: <IRQ> skbpush+0x38/0x40 packetrcvspkt+0xe1/0x170 netifreceiveskbcore.constprop.0+0x7e8/0xd30 ... Kernel panic - not syncing: Fatal exception in interrupt
The socket type is reachable: packetcreate() accepts SOCKPACKET alongside SOCKRAW and SOCKDGRAM behind the same CAPNETRAW check, and neither the socket length nor a capability check keeps it away from a CAN interface.
The missing skbresetheader() calls in initcanskb() are a regression in their own right and are being fixed separately, but a packet socket should not turn a link layer that did not initialise its mac header into a kernel panic. Guard the push the way the other two receive paths do.
Tested on v7.3-rc5 under QEMU with a slcan device on a pty, which is the driver RX path: vcan does not reproduce it, because cansend() resets the headers on the way out. One SOCKPACKET socket bound to can0 and one frame written into the line discipline panics an unpatched kernel with the trace above; the same image with this patch prints no panic and powers off normally. Both kernels are this tree, defconfig plus CONFIGCANSLCAN=y, differing only in this hunk.
Bluetooth: hcisock: Serialize dead-device detachment
drm/i915/gem: Prevent overstepping exec array boundary
In the Linux kernel, the following vulnerability has been resolved:
namespace: check a submount for references right before unmounting it
shrinksubmounts() and markmountsforexpiry() first collect all the mounts they are allowed to unmount and then unmount them.
Whether a mount is busy is decided by propagatemountbusy() on the tree. But unmounting the first mount changes the tree that the second one propagates into. propagateumount() moves a surviving overmount off a copy it unmounts and mounts it where the copy was mounted. If that's where the propagated copy of the second victim is looked up the overmount becomes a candidate of the second umounttree(). It's childless and so trimone() commits it without looking at its reference count.
So a synchronous umount pulls out a busy mount that is in use somewhere else and marks it MNTSYNCUMOUNT while it has users:
umount2(/tmp/plshrink/p1, 0) = 0 errno 0 cwd is (unreachable)
The same two umounts requested one after the other fail with EBUSY. This needs a mount with MNTSHRINKABLE, i.e., automounted submounts of NFS, AFS and CIFS or the tracefs mount below debugfs. Bind mounts inherit the flag.
Check each mount right before it is unmounted under the same hold of namespacesem and mountlock as the umount itself. Make sure that the algorithm stays linear.
In the Linux kernel, the following vulnerability has been resolved:
net/smc: protect clcsock lifetime in smcgetname
smcgetname() dereferences smc->clcsock without holding clcsockreleaselock. Link-group termination can release the CLC socket through smccloseactiveabort() while the SMC socket is still open, for example after shutdown(SHUTWR).
A getsockname() caller can load smc->clcsock, then the termination worker can clear the pointer and call sockrelease() before the caller accesses clcsock->ops or invokes getname(). This causes a use-after-free; if the worker clears the pointer before the load, it causes a NULL dereference. The syscall's file reference keeps the SMC socket alive but does not prevent asynchronous release of its CLC socket.
KASAN reported the following with test-only timing instrumentation:
BUG: KASAN: slab-use-after-free in smcgetname+0x19e/0x1b0 Read of size 8 at addr ffff888109abb4e0 by task poc/103 Call Trace: smcgetname+0x19e/0x1b0 dogetsockname+0xe5/0x170 sysgetsockname+0x8c/0x100
Allocated by task 95: sockallocinode+0x1e/0x280 sockalloc+0x3d/0x240 sockcreate+0x7e/0x430 smccreate+0x121/0x240
Freed by task 0: kmemcachefree+0xcc/0x340 rcucore+0x50a/0x1850
Last potentially related work creation: evict+0x446/0x6c0 smcclcsockrelease+0xa8/0xd0 smccloseactiveabort+0x26a/0x3a0 smclgrterminate.part.0+0x137/0x2e0
Hold clcsockreleaselock across the pointer check and the getname() callback to serialize with smcclcsockrelease(). Return -EBADF if the CLC socket has already been released, preserving the existing peer state check and the callback's return value otherwise.
flowdissector: avoid u16 truncation of skb->len when computing thoff
In the Linux kernel, the following vulnerability has been resolved:
mmc: sdhci-sprd: disable runtime PM on remove
sdhcisprdprobe() enables runtime PM, while sdhcisprdremove() does not perform the corresponding runtime PM cleanup.
The probe failure path disables runtime PM before disabling the clocks, but the normal remove path directly disables clocks that are also managed by the runtime PM callbacks. If the device is runtime suspended, those clocks may already be disabled.
Resume the device before removal, disable runtime PM and drop the temporary runtime PM reference before disabling the clocks.
This issue was found by manual code inspection.
dm: fix reading free memory in doresume
In the Linux kernel, the following vulnerability has been resolved:
selinux: preserve NATIVELABELS on already-initialized sb in setmntopts
When an NFSv4 filesystem exported with securitylabel is mounted a second time, sgetfc() returns the existing superblock and nfsgetroot() calls securitysbsetmntopts() again on it. Since the superblock is already SBINITIALIZED, selinuxsetmntopts() takes an early exit without setting SECURITYLSMNATIVELABELS in setkernflags. nfsgetroot() then sees kflags without SECURITYLSMNATIVELABELS set and clears NFSCAPSECURITYLABEL on the shared nfsserver, silently disabling per-file labeling for both the new and the original mount.
Commit 3815a245b501 ("security/selinux: fix SECURITYLSMNATIVELABELS on reused superblock") fixed the same problem in selinuxsbclonemntopts(). The reused-superblock path for a plain second mount now goes through sbsetmntopts rather than sbclonemntopts, so it needs the same treatment: on both SESBINITIALIZED early exits, set SECURITYLSMNATIVELABELS in setkernflags when the superblock was already using SECURITYFSUSENATVE.
drm/fb-helper: defer setup when fbdevprobe() fails, not just on -EAGAIN
In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: don't leak the skb when xennetfillfrags() fails
When a response chain has more slots than fit in the skb's frags, xennetfillfrags() returns an error and xennetpoll() jumps to its error path. That path moves what's left on tmpq to errq to be freed, but the skb being filled was already dequeued from tmpq, so it's never freed. Each chain that overflows leaks the skb and the pages attached to it as frags, and the backend decides how many slots it sends.
Put the skb back on tmpq before taking the error path, like the xennetsetskbgso() failure just above it does.
In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: drop RX packets with a short Ethernet header
handleincomingqueue() pulls pullto bytes into the head before calling ethtypetrans(). pullto is the length of the first RX slot, capped at RXCOPYTHRESHOLD, and that length comes from the backend. Nothing checks it against ETHHLEN.
If the first slot is shorter than ETHHLEN and more slots follow, the head ends up shorter than an Ethernet header while skb->len is longer, and ethtypetrans() BUG()s in skbpull(). If the whole packet is shorter than ETHHLEN, ethtypetrans() reads the header past the end of the data instead.
Pull at least ETHHLEN, and drop the packet if that fails, which also drops packets too short to hold an Ethernet header. This also checks the return value of the pull, which was ignored.
drm/vc4: drain the hangcheck timer and works on V3D unbind
flowdissector: avoid u16 truncation of hlen in bpfflowdissect()
In the Linux kernel, the following vulnerability has been resolved:
ipv4: do not warn on route notification size race
Commit 680aea08e78c ("net: ipv4: Emit notification when fib hardware flags are changed") added asynchronous route notifications for hardware flag changes.
fibaliashwflagsset() sizes the skb with fibnlmsgsize() and later fills it with fibdumpinfo() while holding only RCU. With nexthop compatibility mode enabled, a concurrent replacement can grow the group between these independent snapshots. fibdumpinfo() can then legitimately return -EMSGSIZE, so the warning does not prove a sizing bug.
Remove the warning. The existing error path still frees the skb and reports the error to listeners.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: emtext: reject unterminated algo before autoload
This is a follow-up to commit 9c572a83037a ("net/sched: fix potential stack infoleak in emtextdump()"), which zero-initialised the dump-side struct. Sashiko pointed at a pre-existing bug that exposed the change-side input-validation gap open.
emtextchange() casts the raw netlink attribute payload to struct tcfemtext and passes conf->algo, a 16-byte array with no enforced NUL terminator, to textsearchprepare(). On the TSAUTOLOAD retry textsearchprepare() calls requestmodule("ts%s", algo); vsnprintf() walks %s until it finds a NUL, so an algo[] with no NUL reads past the array into the adjacent struct fields and payload and feeds those bytes to the usermode helper command line. This is an out-of-bounds read and a kernel memory disclosure.
Reject the attribute when no NUL exists within TCEMTEXTALGOSIZ bytes, matching the check xtstring has had since 3ab720881b6e.
Conditions to recreate the bug: - CAPNETADMIN on the target netns (namespace-local via unshare -Urn is enough) - install clsact on an interface, then add a basic filter with one text ematch whose algo[] is 16 bytes with no NUL (e.g. "A"16) and patternlen at least 1 - the add fails with -ENOENT and the kernel invokes modprobe with a module name made of "ts" plus the 16 bytes and the adjacent payload
btrfs: fix xattr replace when multiple xattrs are packed in the same item
ice: fix metadatadst refcount handling on representor teardown
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: validate transport header presence in setipv6addr
When executing IPv6 address rewrite actions on IPv6 fragments, setipv6addr() calls updateipv6checksum(). If parseipv6hdr() processes a non-first IPv6 fragment, it sets key->ip.proto to NEXTHDRFRAGMENT and returns early without calling skbsettransportheader().
updateipv6checksum() unconditionally evaluates skbtransportoffset() on entry before checking l4proto. Because skb->transportheader is uninitialized, this triggers a warning under CONFIGDEBUGNET=y although it is completely harmless.
Fix this by returning early in updateipv6checksum() if l4proto is NEXTHDRFRAGMENT. This avoids reading the uninitialized transport offset for fragments while preserving the debug warning for any other protocol where the transport header is unexpectedly missing.
See the syzbot trace:
!skbtransportheaderwasset(skb) WARNING: ./include/linux/skbuff.h:3075 at skbtransportheader include/linux/skbuff.h:3075 [inline], CPU#1: syz-executor463/5635 WARNING: ./include/linux/skbuff.h:3075 at skbtransportoffset include/linux/skbuff.h:3250 [inline], CPU#1: syz-executor463/5635 WARNING: ./include/linux/skbuff.h:3075 at updateipv6checksum net/openvswitch/actions.c:361 [inline], CPU#1: syz-executor463/5635 WARNING: ./include/linux/skbuff.h:3075 at setipv6addr+0x462/0x660 net/openvswitch/actions.c:399, CPU#1: syz-executor463/5635 [...] RIP: 0010:skbtransportheader include/linux/skbuff.h:3075 [inline] RIP: 0010:skbtransportoffset include/linux/skbuff.h:3250 [inline] RIP: 0010:updateipv6checksum net/openvswitch/actions.c:361 [inline] RIP: 0010:setipv6addr+0x462/0x660 net/openvswitch/actions.c:399 [...] Call Trace: <TASK> setipv6 net/openvswitch/actions.c:531 [inline] doexecuteactions+0x557e/0x8600 net/openvswitch/actions.c:1366 ovsexecuteactions+0xde/0x520 net/openvswitch/actions.c:1592 ovspacketcmdexecute+0xb4f/0xf10 net/openvswitch/datapath.c:705 genlfamilyrcvmsgdoit+0x233/0x340 net/netlink/genetlink.c:1114 genlrcvmsg+0x614/0x7a0 net/netlink/genetlink.c:1209 netlinkrcvskb+0x226/0x4a0 net/netlink/afnetlink.c:2572 genlrcv+0x28/0x40 net/netlink/genetlink.c:1218 netlinkunicast+0x7bd/0x940 net/netlink/afnetlink.c:1361 netlinksendmsg+0x813/0xb40 net/netlink/afnetlink.c:1916 socksendmsgnosec+0x14e/0x190 net/socket.c:800
drm/i915/gt: Unmask interrupts only when ACTIVE is true
Bluetooth: RFCOMM: free the skb when the DLC has no owner
gpio: xilinx: fix runtime PM leak on request error path
In the Linux kernel, the following vulnerability has been resolved:
workqueue: Fix NULL currentpwq deref in chained work check
currentwqworker() only tells us that %current is a kworker. It does not guarantee that the worker is currently executing a work item, as worker->currentpwq is populated only while processonework() is running the work function.
ischainedwork() can be reached while queueing on a draining or destroying workqueue. If a kworker outside work-item execution reaches that path, currentwqworker() returns a worker but worker->currentpwq is NULL, and the chained-work test can fault before it emits the intended warning.
Guard the chained-work test with worker->currentpwq. A kworker without currentpwq is not executing work on the target workqueue, so the helper should return false and let the draining/destroying warning fire.
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: fix soft lockup in the netlink flow dump
A production compute node carrying a few thousand datapath flows hit a soft lockup inside a single netlink flow dump and panicked.
ovsflowcmddump() calls ovsflowstatsget() for every flow it emits, and that releases stats->lock with spinunlockbh() once per CPU that has touched the flow. Every release is a localbhenable(), and each one runs the pending softirq backlog in the dumping thread's own context.
The skb bounds the flows one callback emits, but not the softirq work it absorbs. On a CPU that carries the box's packet load the backlog refills as fast as it drains, so the dumping thread becomes that CPU's softirq engine. It never sleeps and it has no reschedule point, so under voluntary preemption nothing can take the CPU away from it: neither the ksoftirqd the kernel woke to take the work over, nor the stopper thread the softlockup detector dispatches to refresh its timestamp.
Hold BH off across the whole callback instead, the way ctnetlinkdumptable() does, so the nested spinunlockbh() stop draining softirqs. The loop already runs under rcureadlock() and cannot sleep. What it gives up is preemption under CONFIGPREEMPT, since a BH-off region is not preemptible outside PREEMPTRT. The region stays short: the skb caps the flows one callback emits, and empty buckets cost no skb space but are each visited once per dump, as the cursor only moves forward. The table grows on insert and shrinks only on flush, so the walk is bounded by the largest flow count the datapath has held. The softirq backlog the callback used to absorb has no bound at all.
bnxten: fix DMA mapping length for padded small packets
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: avoid recursive multicast port cleanup
brmulticastsgdelexcludeports() removes automatically added STAREXCL port groups by calling brmulticastdelpg(). For S,G entries, that deletion calls back into brmulticastsgdelexcludeports(), so a large number of STAREXCL ports consumes one kernel stack frame per port and can hit the stack guard page.
Keep the complete port-group deletion path for cleanup, but suppress the S,G exclude-port cleanup while that helper is already walking the same entry. Normal deletion callers retain the existing behavior.