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

USB: serial: digiacceleport: fix memory corruption with small endpoints

Add the missing bulk-out buffer size sanity checks to avoid out-of-bounds memory accesses or slab corruption should a malicious device report smaller buffers than expected.

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

netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without direction check

An unintended behavior in the TCP conntrack state machine allows a connection to be forced into the CLOSE state using an RST packet with an invalid sequence number.

Specifically, after a SYN packet is observed, an RST with an invalid SEQ can transition the conntrack entry to TCPCONNTRACKCLOSE, regardless of whether the RST corresponds to the expected reply direction. The relevant code path assumes the RST is a response to an outgoing SYN, but does not validate packet direction or ensure that a matching SYN was actually sent in the opposite direction.

As a result, a crafted packet sequence consisting of a SYN followed by an invalid-sequence RST can prematurely terminate an active NAT entry. This makes connection teardown easier than intended.

So, tighten the state transition logic to ensure that RST-triggered CLOSE transitions only occur when the RST is a valid response to a previously observed SYN in the correct direction.

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

net: rds: clear isends on setup unwind

The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released.

When rdsibsetupqp() fails after allocating isends but before allocating irecvs, the sendsout path frees isends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation.

Clear isends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.

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

ipv6: mcast: Fix use-after-free when processing MLD queries

When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskbmaypull() calls, leading to a use-after-free [1].

Fix by copying the multicast group address when the packet is initially parsed.

[1] BUG: KASAN: slab-use-after-free in mldquerywork (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118

Workqueue: mld mldquerywork Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:94 lib/dumpstack.c:120) printaddressdescription.constprop.0 (mm/kasan/report.c:378) printreport (mm/kasan/report.c:482) kasanreport (mm/kasan/report.c:595) mldquerywork (net/ipv6/mcast.c:1512) mldquerywork (net/ipv6/mcast.c:1563) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245) </TASK>

[...]

Freed by task 118: kasansavestack (mm/kasan/common.c:57) kasansavetrack (mm/kasan/common.c:78) kasansavefreeinfo (mm/kasan/generic.c:584) kasanslabfree (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskbexpandhead (net/core/skbuff.c:2335) pskbpulltail (net/core/skbuff.c:2878 (discriminator 4)) mldquerywork (net/ipv6/mcast.c:1495 (discriminator 1)) mldquerywork (net/ipv6/mcast.c:1563) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245)

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

tee: optee: prevent use-after-free when the client exits before the supplicant

Commit 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request.

If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free.

Serialise access to the request with supp->mutex:

Hold supp->mutex in opteesupprecv() and opteesuppsend() while looking up and touching the request. Let opteesuppthrdreq() notice that the client has terminated and signal opteesuppsend() accordingly.

With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.

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

netfilter: nftct: bail out on template ct in get eval

I noticed this issue while looking at a historic syzbot report [1].

A rule like the one below is enough to trigger the bug:

table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } }

The first expression attaches a per-cpu template ct via nftctsetzoneeval() (nfcttmplalloc -> kzalloc, tuple is all zero, nfctl3num(ct) == 0). The next expression then calls nftctgeteval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFTREG3215 this overflows past struct nftregs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers.

Reject template ct at the eval entry and in nftctgetfasteval(), mirroring the check nftctseteval() already has. Additionally, bound the address copy in NFTCTSRC / NFTCTDST by priv->len instead of by nfctl3num(ct): nfctgettuple() zeroes the tuple before pkttotuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack.

[1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c

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

Bluetooth: L2CAP: use chan timer to close channels in cleanuplisten()

l2capchanclose() removes the channel from conn->chanl, which must be done under conn->lock. cleanuplisten() runs under the parent sklock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sklock order.

Instead of calling l2capchanclose() directly, schedule l2capchantimeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order.

The timer is only armed when chan->conn is still set: if it is already NULL, l2capconndel() has already processed this channel (l2capchandel + l2capsockteardowncb + l2capsockclosecb), so there is nothing left to do. If l2capconndel() races in after the timer is armed, clearchantimer() inside l2capchandel() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.

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

Bluetooth: ISO: fix UAF in isorecvframe

isorecvframe reads conn->sk under isoconnlock but releases the lock before using sk, with no reference held. A concurrent isosockkill() can free sk in that window, causing use-after-free on sk->skstate and sockqueuercvskb().

Fix by replacing the bare pointer read with isosockhold(conn), which calls sockhold() while the spinlock is held, atomically elevating the refcount before the lock drops. Add a dropput label so sockput() is called on all exit paths where the hold succeeded.

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

mptcp: allow subflow rcv wnd to shrink

In MPTCP connection, the window field in the TCP header refers to the MPTCP-level rcvnxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time.

At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog).

As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving.

Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.

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

tty: serial: pchuart: add check for dmaalloccoherent()

Add a check for dmaalloccoherent() failure to prevent a potential NULL pointer dereference in dmahandlerx(). Properly release DMA channels and the PCI device reference using a goto ladder if the allocation fails.

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

tun: free page on buildskb failure in tunxdpone()

When buildskb() fails in tunxdpone(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhostnetbuildxdp() allocated for the frame. As with the short-frame rejection path, tunsendmsg() discards the per-buffer error and still returns totallen, so vhosttxbatch() takes the success path and never frees the page. Each buildskb() failure in a batch leaks one page-frag chunk.

Free the page before taking the error path, matching the putpage() the other error exits of tunxdpone() already perform.

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

netfilter: nftexthdr: fix register tracking for FPRESENT flag

nftexthdrinit() passes user-controlled priv->len to nftparseregisterstore(), which marks that many bytes in the register bitmap as initialized. However, when NFTEXTHDRFPRESENT is set, the eval paths write only 1 byte (nftregstore8) or 4 bytes (dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nftregs.

Bail out if userspace requests too much data when FPRESENT is set.

drm/i915/gem: Fix phys BO pread/pwrite with offset

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

USB: serial: mxuport: fix memory corruption with small endpoint

Make sure that the bulk-out endpoint max packet size is at least eight bytes to avoid user-controlled slab corruption should a malicious device report a smaller size.

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

usb: typec: tcpm/tcpcimaxim: validate header NDO against RXBYTECNT

A broken/malicious port can transmit a CRC-valid frame whose header advertises up to seven data objects but whose body carries fewer than that. Check for this, and rightfully reject the message, instead of reading from uninitialized stack memory.

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

USB: serial: safeserial: fix memory corruption with small endpoint

Make sure that the bulk-out buffer size is at least eight bytes to avoid user-controlled slab corruption in "safe" mode should a malicious device report a smaller size.

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

net: bonding: fix NULL pointer dereference in bonddoioctl()

In bonddoioctl(), slavedev is obtained via devgetbyname() which can return NULL if the requested interface name does not exist. However, the subsequent slavedbg() call is placed before the NULL check:

slavedev = devgetbyname(net, ifr->ifrslave); slavedbg(bonddev, slavedev, "slavedev=%p:\n", slavedev); //here if (!slavedev) return -ENODEV;

The slavedbg() macro expands to netdevdbg(bonddev, "(slave %s): " fmt, (slavedev)->name, ...) which unconditionally dereferences slavedev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name.

This is reachable from userspace via the bonding ioctl interface with CAPNETADMIN capability, making it a potential local denial-of-service vector.

Fix by moving the slavedbg() call after the NULL check.

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

ip6: vti: Use ip6tnl.net in vti6changelink().

ip netns add ns1 ip netns add ns2 ip -n ns1 link add vti6test type vti6 remote ::1 local ::2 key 7 ip -n ns1 link set vti6test netns ns2 ip -n ns2 link set vti6test type vti6 remote ::3 local ::4 key 9 ip netns del ns2 ip netns del ns1 [ 132.495484] ------------[ cut here ]------------ [ 132.497609] kernel BUG at net/core/dev.c:12376!

Commit 61220ab34948 ("vti6: Enable namespace changing") dropped NETIFFNETNSLOCAL from vti6 devices. A vti6 tunnel can then move through IFLANETNSFD. After the move devnet(dev) points at the new netns while t->net stays at the creation netns.

vti6changelink() and vti6update() still use devnet(dev) and devnet(t->dev). They unlink from one per netns hash and relink into another. The creation netns is left with a stale entry. cleanupnet() of that netns later walks freed memory.

Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). Cross tenant scope on container hosts.

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:

misc: fastrpc: fix use-after-free of fastrpcuser in workqueue context

There is a race between fastrpcdevicerelease() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpcdevicerelease() frees the fastrpcuser structure. Concurrently, an in-flight DSP invocation can complete and fastrpcrpmsgcallback() schedules context cleanup via schedulework(&ctx->putwork). If the workqueue runs fastrpccontextfree() in parallel with or after fastrpcdevicerelease() has freed the user structure, it dereferences the freed fastrpcuser. Depending on the state of the context at the time of the race, any one of the following accesses can be hit:

1. fastrpcbuffree() calls fastrpcipatodmaaddr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dmafreecoherent().

2. fastrpcfreemap() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcomscmassignmem() call that returns memory from the DSP VM back to HLOS.

3. fastrpcfreemap() acquires map->fl->lock to safely remove the map node from the fl->maps list.

The resulting use-after-free manifests as:

pc : fastrpcbuffree+0x38/0x80 [fastrpc] lr : fastrpccontextfree+0xa8/0x1b0 [fastrpc] fastrpccontextfree+0xa8/0x1b0 [fastrpc] fastrpccontextputwq+0x78/0xa0 [fastrpc] processonework+0x180/0x450 workerthread+0x26c/0x388

Add kref-based reference counting to fastrpcuser. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpcdevicerelease() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpcuserfree(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.

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

auxdisplay: line-display: fix OOB read on zero-length messagestore()

linedispdisplay() unconditionally reads msg[count - 1] before checking whether count is zero, so a write of zero bytes to the message sysfs attribute hits msg[-1]:

write(fd, "", 0);

-> messagestore(..., buf, count=0) -> linedispdisplay(linedisp, buf, count=0) -> msg[count - 1] == '\n' ; OOB read

The kernfs write buffer for that store is a 1-byte allocation (kernfsfopwriteiter() does kmalloc(len + 1) with len == 0), so msg[-1] is a 1-byte read before the slab object. On a KASAN-enabled kernel this trips an out-of-bounds report and panics; on stock kernels it silently reads adjacent slab data and, if that byte happens to be '\n', the following count-- wraps ssizet 0 to -1 and is then passed to kmemdupnul().

linedispdisplay() is reached from the messagestore() sysfs callback (drivers/auxdisplay/line-display.c message attribute, mode 0644) and from the in-tree initial-message setup with count == -1, so the OOB path is only userspace-triggerable via zero-byte writes; vfswrite() does not short-circuit on count == 0 and kernfsfopwriteiter() dispatches the store callback regardless.

Guard the trailing-newline trim with a count check. The existing if (!count) block then takes the clear-display path unchanged.

Affects every auxdisplay driver that registers via linedispregister() / linedispattach(): ht16k33, max6959, img-ascii-lcd, seg-led-gpio.

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

usb: dwc2: Fix use after free in debug code

We're not allowed to dereference "urb" after calling usbhcdgivebackurb() so save the urb->status ahead of time.

dm cache policy smq: check allocation under invalidate lock

A flaw in the Linux kernel's ebtables SNAT target allows writing to shared memory pages when rewriting ARP sender hardware addresses without ensuring writability, potentially causing file/memory corruption or denial of service.

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

scsi: scsitransportfc: Widen FPIN pname walker counter to u32

An adjacent Fibre Channel fabric actor that can deliver an FPIN ELS frame to an lpfc or qla2xxx Linux initiator can trigger a non-return in the generic FC transport. This is not a local userspace or IP network path; the attacker must be able to inject fabric traffic, for example as a compromised switch or fabric controller, or as a same-zone NPort on a fabric that permits source spoofing.

The Link-Integrity and Peer-Congestion FPIN walkers used a u8 loop counter against the 32-bit on-wire pnamecount field, and did not bound pnamecount by the descriptor body already validated by the TLV walker. A pnamecount of 256 therefore wraps the counter and keeps the loop condition true indefinitely.

Factor the shared pnamelist[] walk into one helper, widen the counter to u32, and clamp pnamecount against the entries that fit in the descriptor body before iterating.

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

HID: wacom: Fix OOB write in wacomhidsetdevicemode()

wacomhidsetdevicemode() currently assumes that the HIDDGINPUTMODE usage is always located in the first field (field[0]) of the feature report. However, a device can specify HIDDGINPUTMODE in a different field.

If HIDDGINPUTMODE is in a field other than the first one and the first field has a reportcount smaller than the usageindex of HIDDGINPUTMODE, this leads to an out-of-bounds write to r->field[0]->value.

Fix this by storing the field index of HIDDGINPUTMODE in 'struct hiddata' during feature mapping. In wacomhidsetdevicemode(), use this stored field index to access the correct field and add bounds checks to ensure both the field index and the value index are within valid ranges before writing.

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

iio: chemical: scd30: fix division by zero in writeraw

Add a zero check for val2 before using it as a divisor when setting the sampling frequency. A user writing a zero fractional part to the samplingfrequency sysfs attribute triggers a division by zero in the kernel.

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

sctp: diag: reject stale associations in dumpone path

The SCTP exact sockdiag lookup can hold a transport reference, block on locksock(sk), and then resume after sctpassociationfree() has marked the association dead and freed its bind address list.

When that happens, inetassocattrsize() and inetdiagmsgsctpasocfill() can still dereference association state that is no longer valid for reporting. In particular, inetdiagmsgsctpasocfill() may read an empty bind-address list as a real sctpsockaddrentry and trigger an out-of-bounds read from unrelated association memory.

Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.

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

scsi: fcoe: Reject FIP descriptors with zero fipdlen in CVL walker

drivers/scsi/fcoe/fcoectlr.c::fcoectlrrecvclrvlink() advanced the descriptor cursor by an attacker-supplied fipdlen without ever requiring dlen >= sizeof(struct fipdesc) in the default branch. The named descriptor cases (FIPDTMAC, FIPDTNAME, FIPDTVNID) checked their per-type minimum lengths, but a FIPDTNONCRITICAL descriptor (fipdtype >= 128, which the standard requires receivers to silently ignore) skipped that check entirely.

An unauthenticated L2 peer on the FCoE control VLAN could hang fcoectlrrecvwork on an fcoe, qedf, or bnx2fc initiator indefinitely by emitting one FIP CVL frame whose single descriptor had fipdtype == FIPDTNONCRITICAL and fipdlen == 0: the cursor advanced zero bytes per iteration and the loop condition rlen >= sizeof(desc) stayed true forever, blocking every subsequent FIP frame on that controller.

Tighten the outer dlen guard to also reject dlen < sizeof(struct fipdesc), so a malformed descriptor whose length cannot even cover the descriptor header is rejected before the switch. This is the same lower-bound the named cases already apply and is the minimum scope that closes the loop.

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

net/rds: fix NULL deref in rdsibsendcqehandler() on masked atomic completion

rdsibxmitatomic() always programs a masked atomic opcode (IBWRMASKEDATOMICCMPANDSWP or IBWRMASKEDATOMICFETCHANDADD) for every RDS atomic cmsg. But the completion-side switch in rdsibsendunmapop() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->sop is left set. rdsibsendcqehandler() then dereferences the NULL rm via rm->mfinalop, oopsing in softirq context. An unprivileged AFRDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed.

RDS/IB: rdsibsendunmapop: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rdsibsendcqehandler+0x25c/0xb10 (net/rds/ibsend.c:282) Call Trace: <IRQ> rdsibsendcqehandler (net/rds/ibsend.c:282) pollscq (net/rds/ibcm.c:274) rdsibtaskletfnsend (net/rds/ibcm.c:294) taskletactioncommon (kernel/softirq.c:943) handlesoftirqs (kernel/softirq.c:573) runksoftirqd (kernel/softirq.c:479) </IRQ> Kernel panic - not syncing: Fatal exception in interrupt

Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rdsmessage.atomic union member, so the existing containerof()/rdsibsendunmapatomic() body is correct for them.