In the Linux kernel, the following vulnerability has been resolved:
smb: client: clear ce->tgthint in freetgts()
When freetgts() frees all structures in ce->tlist, ce->tgthint is left pointing to one of the freed cachedfstgt structures.
If ce->tgthint is not reset before it is used later, it results in a use-after-free.
Set ce->tgthint to NULL in freetgts() after the elements are freed to reflect that no elements remain.
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: cortina: Make RX SKB per-port
The SKB used to assemble packets from fragments in gmacrx() is static local, but the Gemini has two ethernet ports, meaning there can be races between the ports on a bad day if a device is using both.
Make the RX SKB a per-port variable and carry it over between invocations in the port struct instead.
Zero the pointer once we call napigrofrags(), on error (after calling napifreefrags()) or if the port is stopped.
Zero it in some place where not strictly necessary just to emphasize what is going on.
This was found by Sashiko during normal patch review.
dmaengine: idxd: fix double free of wq, engine, and group structs
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: bound Read Response placement to the RREAD length
In drivers/infiniband/sw/siw/siwqprx.c, siwprocrresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siwchecksge() resolves and validates the sink memory only on the first fragment (the if (!mem) branch), and siwrrespcheckntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->moreddpsegs guard).
A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siwrxdata() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege.
Bound every segment before placement, exactly as siwprocsend() and siwprocwrite() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer.
This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer.
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Bound the early ACPI HID map
The ivrsacpihid command-line parser appends entries to a fixed four-element earlyacpihidmap array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size.
Check the capacity at the common found label before parsing the HID and UID or writing the entry.
In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: Fix potential UAF when ddgst mismatch
Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2CDATA PDU during an R2T-based data transfer, the digest error handler in nvmettcptryrecvddgst() calls nvmetrequninit() — which performs percpurefput() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytesdone, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmettcpuninitdataincmds() iterates all commands, checks nvmettcpneeddatain() for each one, and finds that the already-uninited command still appears to need data (because rbytesdone < transferlen and cqe->status == 0). It therefore calls nvmetrequninit() a second time on the same command — a double percpurefput against a single percpurefget.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: seg6: clear IPv4 control block on IPIP decapsulation
End.DX4 and End.DT4 decapsulate an IPv4 packet through decapandvalidate() and send it directly to IPv4 routing. The inner packet therefore bypasses iprcvcore(), which normally clears IPCB before IPv4 interprets skb->cb.
The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts.
The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6destoptrcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40.
Both tcpv4saveoptions() and ipoptionsecho() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls ipoptionsecho(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so ipoptionsecho() copies 255 bytes into the 40-byte option-data area.
Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced:
BUG: KASAN: slab-out-of-bounds in ipoptionsecho() Write of size 255
The relevant End.DX4 call path is:
ipoptionsecho tcpv4routereq tcpconnrequest tcpv4connrequest tcprcvstateprocess tcpv4dorcv tcpv4rcv ipprotocoldeliverrcu iplocaldeliverfinish iplocaldeliver inputactionenddx4finish inputactionenddx4
The relevant End.DT4 call path is:
ipoptionsecho tcpv4routereq tcpconnrequest tcpv4connrequest tcprcvstateprocess tcpv4dorcv tcpv4rcv ipprotocoldeliverrcu iplocaldeliverfinish iplocaldeliver inputactionenddt4
tcpv4saveoptions() is inlined into the tcpv4routereq() path, so it does not appear as a separate frame.
When decapandvalidate() handles IPPROTOIPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm.
Use IP6CB(skb)->iif rather than skb->skbiif. These actions run after l3mdev processing, which can replace skbiif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.
In the Linux kernel, the following vulnerability has been resolved:
sctp: stop processing a packet once its association is deleted
sctpendpointbhrcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference.
A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctpsfdo92final(), so the association and its transports are freed.
The endpoint loop has no counterpart to the asoc->base.dead check in sctpassocbhrcv(). The next chunk writes to lasttimeheard in the freed transport and is then passed to sctpdosm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context.
The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctpinqfree() releases the chunk on the association receive path.
sctpsfdo524dupcook() issues SCTPCMDDELETETCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone.
In the Linux kernel, the following vulnerability has been resolved:
super: fix emergency thaw deadlock on frozen block devices
dothawallcallback() calls bdevthaw() while holding sb->sumount exclusively. If the block device was frozen via bdevfreeze() dropping the last block layer freeze reference calls fsbdevthaw() which reacquires sumount:
dothawallcallback(sb) superlockexcl(sb) # holds sb->sumount bdevthaw(sb->sbdev) mutexlock(&bdev->bdfsfreezemutex) # bdfsfreezecount drops 1 -> 0 bdholderops->thaw == fsbdevthaw getbdevsuper(bdev) bdevsuperlock(bdev, true) superlock(sb, true) downwrite(&sb->sumount) # same task: deadlock
The emergency thaw worker deadlocks against itself holding both sumount and bdfsfreezemutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device.
[ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 taskflags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events dothawall [ 81.886656] Call Trace: [ 81.887759] <TASK> [ 81.888763] schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedulepreemptdisabled+0x15/0x30 [ 81.893848] rwsemdownwriteslowpath+0x1ea/0x900 [ 81.895191] ? pfxdothawallcallback+0x10/0x10 [ 81.896528] downwrite+0xbd/0xc0 [ 81.897505] superlock+0x91/0x180 [ 81.898457] ? mutexlock+0xa99/0x1140 [ 81.900748] ? mutexunlockslowpath+0x1f/0x400 [ 81.902069] bdevsuperlock+0x5b/0x150 [ 81.903132] getbdevsuper+0x10/0x60 [ 81.904042] fsbdevthaw+0x23/0xf0 [ 81.904755] bdevthaw+0x82/0x100 [ 81.905484] dothawallcallback+0x2c/0x50 [ 81.906298] iteratesupers+0x5d/0x130 [ 81.907067] dothawall+0x20/0x40 [ 81.907739] processonework+0x206/0x5e0 [ 81.908545] workerthread+0x1e2/0x3c0 [ 81.909339] ? pfxworkerthread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? pfxkthread+0x10/0x10 [ 81.911528] retfromfork+0x2e2/0x3b0 [ 81.912259] ? pfxkthread+0x10/0x10 [ 81.913010] retfromforkasm+0x1a/0x30 [ 81.913806] </TASK>
bdevsuperlock() even documents the violated requirement with lockdepassertnotheld(&sb->sumount).
Acquiring bdfsfreezemutex under sumount also inverts the bdfsfreezemutex vs. sumount ordering established by bdev{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit.
Fix this by not holding sumount around the bdevthaw() loop at all. Pin the superblock with an active reference instead as filesystemsfreezecallback() does. The active reference keeps the superblock from being shut down and so ->sbdev stays valid without holding sumount. The block-layer-held freeze is dropped by fsbdevthaw() with FREEZEMAYNEST | FREEZEHOLDERUSERSPACE exactly as a regular unfreeze would and thawsuperlocked() handles filesystem-level freezes as before.
The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thawbdev() already ended in thawsuper() with sumount held by dothawallcallback().
In the Linux kernel, the following vulnerability has been resolved:
nfsd: set SCSTATUSFREED in nfsd4droprevokedstid for delegations
nfsd4droprevokedstid() handles FREESTATEID for admin-revoked delegations but does not set SCSTATUSFREED before releasing cllock. revokedelegation() uses this flag to detect whether FREESTATEID has already processed the delegation -- without it, the freed delegation is added to clrevoked via listadd(), producing a use-after-free when clrevoked is later traversed in destroyclient().
The SCSTATUSREVOKED path in nfsd4freestateid() (line 7983) already sets SCSTATUSFREED correctly. Apply the same pattern to the SCSTATUSADMINREVOKED path in nfsd4droprevokedstid().
In the Linux kernel, the following vulnerability has been resolved:
ice: reject out-of-range ptype in iceparserprofileinit
setbit(rslt->ptype, prof->ptypes) operates on a DECLAREBITMAP of ICEFLOWPTYPEMAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault.
Reproduced with a custom kernel module injecting a crafted VIRTCHNLOPADDRSSCFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1.
crashparser: iceparserprofileinit @ ffffffffc0d61b60 crashparser: setting ptype=0xffff (max valid=1023) crashparser: calling iceparserprofileinit -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:iceparserprofileinit+0x2d/0x1d0 [ice] Call Trace: <TASK> ? pfxiceparserprofileinit+0x10/0x10 [ice] crashinit+0x127/0xff0 [crashparser] dooneinitcall+0x45/0x310 doinitmodule+0x64/0x270 initmodulefromfile+0xcc/0xf0 idempotentinitmodule+0x17b/0x280 x64sysfinitmodule+0x6e/0xe0
Bail out early with -EINVAL when ptype is out of range.
In the Linux kernel, the following vulnerability has been resolved:
nvmet-auth: Synchronize timeout work during SQ teardown
nvmetauthsqfree() cancels authexpiredwork with canceldelayedwork(). If the work has already started, cancellation does not wait for the callback. Transport teardown can consequently free or reuse the queue containing struct nvmetsq while nvmetauthexpiredwork() still accesses that SQ.
Add a teardown-specific helper that synchronously drains the delayed work before freeing authentication state, and use it from nvmetsqdestroy(). Keep the non-synchronous helper for in-band authentication state cleanup, where the SQ owner remains alive.
In the Linux kernel, the following vulnerability has been resolved:
watchdog: pretimeout: Fix UAF in watchdogunregistergovernor()
When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to defaultgov.
If the governor being unregistered is currently set as defaultgov, the defaultgov is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling defaultgov. 2. Existing watchdog devices using the unregistered governor will have their wdd->gov reassigned to the dangling defaultgov.
Fix the UAF by clearing defaultgov if it matches the governor being unregistered.
ila: reload IPv6 header after pskbmaypull in checksum adjust
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Avoid double completion in async IOCB timeout
qla2x00asynciocbtimeout() tries to abort a timed-out async IOCB. When qla24xxasyncabortcmd() fails, both the SRBLOGINCMD path and the SRBCTRLVP/default path scan outstandingcmds[] for the SRB and then call sp->done(sp, QLAFUNCTIONTIMEOUT) unconditionally, without checking whether the SRB was actually found and removed.
If the response ISR completes the same handle first, it removes the SRB under qplockptr and runs sp->done() -> complete(sp->comp). The submitter qla24xxcontrolvp() wakes from waitforcompletion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qlactrlvpspdone(), which evaluates "if (sp->comp) complete(sp->comp)"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free.
Track whether this path removed the SRB from outstandingcmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the spfound guard already used in qla24xxabortiocbtimeout().
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:
sctp: keep chunk->transport in step with the list it is queued on
sctpoutqflushrtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport:
if (chunk->tsngapacked) { listmovetail(&chunk->transmittedlist, &transport->transmitted); continue; }
The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctpassocrmpeer() from an ASCONF Delete-IP - sctptransportfree() RCU-frees it and the chunk is left with a dangling pointer. sctpassocrmpeer() scrubs peer->transmitted and asoc->outqueue.outchunklist, but the chunk is on neither.
The pointer is not followed while tsngapacked is set. A SACK that reneges on the TSN clears the flag, and the next SACK reaches
tchunk->transport->flightsize -= sctpdatasize(tchunk);
inside the freed transport. KASAN reports a slab-use-after-free read in sctpchecktransmitted(), freed from sctpassocrmpeer(). Both the removal and the SACKs come from the association peer.
Set chunk->transport at the move. The ordinary resend path needs nothing: it reaches its listmovetail() only after sctppacketappendchunk() returned SCTPXMITOK, and sctppacketappendchunk() has rebound the chunk by then.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
In the Linux kernel, the following vulnerability has been resolved:
dibs: initialise dibs->lock in dibsdevalloc()
dibs->lock is initialised by dibsdevadd(), but a dibs device can already take interrupts before that call: ismprobe() runs ismdevinit(), and hence requestirq(), before it calls dibsdevadd(). No client can have registered a dmb at that point, so no dmb interrupt can occur, but a GID event interrupt can, and ismhandleirq() takes dibs->lock unconditionally on entry, before it inspects anything else.
Initialise the lock in dibsdevalloc() instead, so that it is valid as soon as a driver can publish the device to its interrupt handler.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: fix integer overflow in immediate data length check
immbuf->len is a user-controlled uint32t received from the network. Adding it to immdataoffset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing reqsize to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sginitone().
Use checkaddoverflow() to detect wrapping before the comparison.
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: wait for in-flight client TLS handshake callback
xstlshandshakesync() gives xstlshandshakedone() a reference to the lower transport before submitting the handshake request. On timeout or signal, the synchronous waiter drops that reference after calling tlshandshakecancel().
handshakereqcancel() returns false when handshakecomplete() has already marked the request complete. In that case the completion callback can still be running, so dropping the callback-owned reference in the waiter can free the lower transport before xstlshandshakedone() stores xprterr or drops its own reference.
If cancellation loses to completion, wait until xstlshandshakedone() signals handshakedone and let the callback release its reference. This mirrors the server-side handshake lifetime handling and keeps the timeout or signal return value unchanged.
Bluetooth: mgmt: hold reference for hciconn in mgmtpendingcmds
ata: satadwc460ex: enable SATA interrupts only after IRQ handler is registered
In the Linux kernel, the following vulnerability has been resolved:
lockd: pin next file across nlminspectfile lock-drop
nlmtraversefiles() pins the current file with fcount++ across a mutexunlock for nlminspectfile(), but nothing pins the saved next pointer. A concurrent nlmreleasefile() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step.
Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock.
Always call nlmfilerelease() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlmfileinuse(), which does a live walk of the inode lock list, rather than the cached flocks field, so skipped files that never ran nlminspectfile() are evaluated correctly.
Because every file in a hash bucket is now pinned and released, files skipped by the isfailoverfile predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table.
In the Linux kernel, the following vulnerability has been resolved:
In the Linux kernel, the following vulnerability has been resolved:
nfsd: size fhverify server sockaddr slot by xptlocallen
The nfsdfhverify and nfsdfhverifyerr tracepoints declare the server sockaddr slot sized by xptremotelen but fill it from xptlocal using xptlocallen:
TPSTRUCTentry( ... sockaddr(server, rqstp->rqxprt->xptremotelen) ... ) TPfastassign( ... assignsockaddr(server, &rqstp->rqxprt->xptlocal, rqstp->rqxprt->xptlocallen); ... )
When xptlocallen exceeds xptremotelen, assignsockaddr's memcpy writes past the reserved ring-buffer slot. In the reverse direction (xptlocallen < xptremotelen) the slot is oversized and the unwritten tail leaks prior ring-buffer contents to trace consumers.
The write-past-end case is reachable on NFS/UDP. svcxprtsetremote() is only called from svctcpaccept() (net/sunrpc/svcsock.c) and from the RDMA connect path; svccreatesocket() for UDP calls only svcxprtsetlocal(), so xptremotelen stays 0 for the xprt's lifetime. Every fhverify trace for an NFSv2/v3-over-UDP request then copies 16 or 28 bytes from xptlocal into a zero-byte slot.
The other NFSD tracepoints that record the server address (NFSDTRACEPROCCALLFIELDS, NFSDTRACEPROCRESFIELDS, SVCRQSTENDPOINTFIELDS) already size the server slot by xptlocallen; nfsdfhverify and nfsdfhverifyerr were the only exceptions.
Fix by sizing the server slot with xptlocallen so the declared slot matches the copy length. The client slot and its assignment already agree on xptremotelen and are left untouched.
In the Linux kernel, the following vulnerability has been resolved:
net/9p: fix race condition on rdma->state in transrdma.c
The rdma->state field is modified without holding reqlock in both recvdone() and p9cmeventhandler(), while rdmarequest() accesses the same field under the reqlock spinlock. This inconsistent locking creates a race condition:
- recvdone() running in softirq completion context sets rdma->state = P9RDMAFLUSHING without acquiring reqlock
- p9cmeventhandler() modifies rdma->state at multiple points (ADDRRESOLVED, ROUTERESOLVED, ESTABLISHED, CLOSED) without reqlock
- rdmarequest() uses spinlockirqsave(&rdma->reqlock, flags) to protect the read-modify-write of rdma->state
The race can cause lost state transitions: recvdone() or the CM event handler could set state to FLUSHING/CLOSED while rdmarequest() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown.
Fix by adding reqlock protection to all rdma->state modifications in recvdone() and p9cmeventhandler(), matching the pattern already used in rdmarequest(). Use spinlockirqsave/spinunlockirqrestore in the CM event handler since it can race with recvdone() which runs in softirq context.
Tested with a kernel module that races two threads (simulating rdmarequest and recvdone/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.
In the Linux kernel, the following vulnerability has been resolved:
ip6tunnel: clear skb2->cb[] in ip6ip6err()
ip6ip6err() clones an outer IPv6 ICMP error skb, pulls it to the quoted inner IPv6 packet, and then passes the clone to icmpv6send(). The clone still carries the outer packet's inet6skbparm in skb->cb.
If the outer packet had a Home Address Option, IP6CB(skb2)->dsthao remains non-zero after skbpull(). icmpv6send() later calls mip6addrswap(), which uses that stale dsthao offset against the quoted inner packet. A malformed inner destination-options header can then make the HAO lookup and address swap run past the end of the quoted packet and corrupt skbsharedinfo.
Clear skb2->cb[] before pulling the quoted inner IPv6 packet so the reply path does not reuse metadata left by the outer IPv6 stack.
In the Linux kernel, the following vulnerability has been resolved:
svcrdma: Reject inline replies that overflow the pull-up buffer
An RPC-over-RDMA client can request a reply, such as an NFS READ payload, without providing a Write list or a Reply chunk to carry it. When such a reply needs more scatter/gather entries than the device's Send Queue supports, svcrdmapullupneeded() selects pull-up and svcrdmapullupreplymsg() linearizes the whole reply into sctxt->scxprtbuf. That buffer is only scmaxreqsize bytes, while the reply on this path is bounded only by the client's request, so svcrdmaxblinearize() copies past the end of the buffer and corrupts adjacent slab memory. The oversized length is then stored in scsges[0].length and posted, so the device also reads beyond the mapped region.
The SGE-exhaustion branch is the only pull-up path that can exceed the buffer: the threshold branch pulls up only replies smaller than RPCRDMAPULLUPTHRESH, and replies that fit the device's SGE budget are sent directly without linearization. Make svcrdmapullupneeded() report -E2BIG when the reply it would pull up cannot fit scmaxreqsize, and fail the request with ERRCHUNK as RFC 8166 Section 4.5.3 directs rather than dropping the connection.
The helper no longer answers a simple yes/no question: it now reports pull-up, no pull-up, or -E2BIG for a reply too large to linearize. Rename svcrdmapullupneeded() to svcrdmacheckpullup() so its name no longer implies a boolean predicate.
In the Linux kernel, the following vulnerability has been resolved:
libceph: refresh auth->authorizerbuf{,len} after authorizer update
cephxcreateauthorizer() caches au->buf->vec.iovbase and au->buf->vec.iovlen in struct cephauthhandshake. These cached values are then used by the messenger connect code when sending the authorizer.
cephxupdateauthorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, cephxbuildauthorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, cephbufferput() frees the old cephbuffer and its vec.iovbase, but auth->authorizerbuf still points at that freed memory.
A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in copyfromiter() while tcpsendmsg() copies the authorizer.
Refresh auth->authorizerbuf and auth->authorizerbuflen after a successful authorizer rebuild so the messenger sends the current buffer.
In the Linux kernel, the following vulnerability has been resolved:
media: stm32: dcmi: unregister notifier on probe failure
dcmigraphinit() registers the async notifier before dcmiprobe() toggles the reset line. If resetcontrolassert() or resetcontroldeassert() fails afterwards, probe returns through errcleanup and the driver core will not call dcmiremove().
Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules.
[hverkuil: added Fixes tag]