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

wifi: ath12k: fix memory leak in ath12kservicereadyextevent

Currently, in ath12kservicereadyextevent(), svcrdyext.macphycaps is not freed in the failure case, causing a memory leak. The following trace is observed in kmemleak:

unreferenced object 0xffff8b3eb5789c00 (size 1024): comm "softirq", pid 0, jiffies 4294942577 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 7b 00 00 10 ............{... 01 00 00 00 00 00 00 00 01 00 00 00 1f 38 00 00 .............8.. backtrace (crc 44e1c357): kmallocnoprof+0x30b/0x410 ath12kwmimacphycapsparse+0x84/0x100 [ath12k] ath12kwmitlviter+0x5e/0x140 [ath12k] ath12kwmisvcrdyextparse+0x308/0x4c0 [ath12k] ath12kwmitlviter+0x5e/0x140 [ath12k] ath12kservicereadyextevent.isra.0+0x44/0xd0 [ath12k] ath12kwmioprx+0x2eb/0xd70 [ath12k] ath12khtcrxcompletionhandler+0x1f4/0x330 [ath12k] ath12kcerecvprocesscb+0x218/0x300 [ath12k] ath12kpciceworkqueue+0x1b/0x30 [ath12k] processonework+0x219/0x680 bhworker+0x198/0x1f0 taskletaction+0x13/0x30 handlesoftirqs+0xca/0x460 irqexitrcu+0xbe/0x110 irqexitrcu+0x9/0x30

Free svcrdyext.macphycaps in the error case to fix this memory leak.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPLSILICONZ-1

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.

forcedeth: fix off-by-one when saving/restoring non-PCI config space

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

svcrdma: Fix pclforeachsegment for empty chunks

When a parsed chunk list contains a chunk whose chsegcount is zero, pclforeachsegment computes its inclusive upper bound as &chunk->chsegments[chsegcount - 1]. chsegcount is u32, so the subtraction wraps to 0xFFFFFFFF and the bound lands far past the chsegments flex array. The loop body then walks unrelated memory at sizeof(struct svcrdmasegment) stride until it faults.

A zero-segcount chunk is reachable from the wire: xdrcheckwritechunk() only rejects segcount values greater than rcmaxpages, and pclallocwrite() links a freshly allocated chunk onto rcwritepcl/rcreplypcl before its segment-fill loop runs, so a Write or Reply chunk advertising zero segments leaves chsegcount == 0 on the list. When the transport has negotiated Send-With-Invalidate, svcrdmagetinvrkey() iterates all four PCLs with pclforeachsegment and dereferences segment->rshandle on each iteration, turning the underflow into an out-of-bounds read and a general protection fault.

xdrcheckwritelist / xdrcheckreplychunk pclallocwrite() chunk = pclallocchunk(...) / chsegcount = 0 / listaddtail(&chunk->chlist, &pcl->clchunks) / fill loop iterates zero times for wire segcount 0 /

svcrdmagetinvrkey() pclforeachchunk(rcwritepcl) pclforeachsegment(segment, chunk) pos <= &chsegments[0u - 1u] / 0xFFFFFFFF / segment->rshandle / OOB read -> GPF /

Fix by switching the macro to a half-open upper bound that uses chsegcount directly. For chsegcount == 0 the loop start equals the loop end and the body is skipped; for chsegcount > 0 the iteration range is unchanged. All six existing call sites in net/sunrpc/xprtrdma/svcrdmarecvfrom.c and net/sunrpc/xprtrdma/svcrdmarw.c remain correct under the new bound, so no caller changes are needed.

devlink: fix net namespace reference leak in reload

futex: Prevent robust futex exit race some more

can: j1939: transport: j1939sessionfreshnew(): initialize receive buffer

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

vsock/virtio: avoid refilling the RX queue after teardown

Commit b917507e5ad9 ("vsock/virtio: stop workers during the .remove()") made the RX worker jump to its common exit when rxrun is clear. That exit still refills the RX queue when the buffer count is low, so work queued across virtiovsockvqsdel() can add buffers after the virtqueues have been deleted.

BUG: KASAN: slab-use-after-free in virtqueueaddsgs Read of size 4 by task kworker/0:1 Workqueue: virtiovsock virtiotransportrxwork Call Trace: virtqueueaddsgs (drivers/virtio/virtioring.c:2796) virtiovsockrxfill (net/vmwvsock/virtiotransport.c:332) virtiotransportrxwork (net/vmwvsock/virtiotransport.c:701) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245) ... Freed by task 141: kfree (mm/slub.c:6566) vpdelvq (drivers/virtio/virtiopcicommon.c:259) vpdelvqs (drivers/virtio/virtiopcicommon.c:285) virtiovsockfreeze (net/vmwvsock/virtiotransport.c:912) virtiodevicefreeze (drivers/virtio/virtio.c:658) virtiopcifreeze (drivers/virtio/virtiopcicommon.c:601) pcipmfreeze (drivers/pci/pci-driver.c:1098) devicesuspend (drivers/base/power/main.c:1968) Kernel panic - not syncing: KASAN: paniconwarn set ...

Jump to a no-refill exit when rxrun is clear, leaving the normal exit to replenish a running queue.

efivarfs: Rate limit statfs() handler

hwmon: (nct6775-core) Fix number of temperature registers for NCT6116

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:

ipv6: fix Route Information option length validation

rt6routercv() validates the Route Information option (RFC 4191) length against the prefix length, but both checks are off by one.

rinfo->length is the ND option length in units of 8 octets and it includes the 8-byte option header, so an option carrying N bytes of prefix has length == 1 + N/8. RFC 4191 section 2.3 requires length 3 when Prefix Length is greater than 64, and 2 or 3 when it is greater than 0. The code accepts length >= 2 and length >= 1 respectively.

ipv6addrprefix() then copies prefixlen/8 bytes out of rinfo->prefix, so a Router Advertisement with (prefixlen=128, length=2) or (prefixlen=64, length=1) makes the kernel read up to 8 bytes past the end of the option. Those bytes end up in the prefix of the route that gets installed, so they are visible to userspace:

# RA with a Route Information option (prefixlen=128, length=2) # followed by a source link-layer address option, 01 01 de ad be ef ca fe $ ip -6 route show 2001:db8:dead:beef:101:dead:beef:cafe via fe80::1234 dev veth0 proto ra ^^^^^^^^^^^^^^^^^^ the next option, read out of bounds

When the Route Information option is the last one in the packet, those eight bytes come from the skb tail room instead.

Reject the option lengths RFC 4191 does not allow.

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

ipmi: si: Fix NULL pointer dereference after failed registration

trysmiinit() allocates newsmi->sism and later calls ipmiregistersmimod(), which maps to ipmiaddsmi().

During ipmiaddsmi(), the upper IPMI message handler obtains the initial BMC device information through bmcgetdeviceid(). This can fail if the BMC does not return a successful response to the Get Device ID command.

When the BMC returns a nonzero completion code, the device-id helper retries the command and eventually returns -EIO if the device ID still cannot be fetched.

On this failure path, ipmiaddsmi() logs "Unable to get the device id" and goes to outerrstarted, where it invokes the lower driver's shutdown callback. trysmiinit() then logs the returned registration failure:

ipmisi IPI0001:00: IPMI message handler: Unable to get the device id: -5 ipmisi IPI0001:00: Unable to register device: error -5

For ipmisi, the shutdown callback is shutdownsmi(), which cleans up the SI state machine data, frees smiinfo->sism, and sets smiinfo->sism and smiinfo->intf to NULL.

However, intf->inshutdown is not set on this failed-registration rollback path. Therefore, the asynchronous redobmcreg work item can still retry BMC device-id probing after the lower driver has already cleared its SI state machine data. In the observed case, that retry path reached startnextmsg(), which passed the NULL smiinfo->sism pointer to the selected KCS state machine handler:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Workqueue: events redobmcreg [ipmimsghandler] RIP: startkcstransaction+0x2c/0x190 [ipmisi] Call Trace: startnextmsg+0x50/0x80 [ipmisi] checkstarttimerthread.part.9+0x3b/0x50 [ipmisi] sender+0x69/0x80 [ipmisi] iipmirequest+0x2ac/0x9d0 [ipmimsghandler] getdeviceid.isra.29+0xaa/0x180 [ipmimsghandler] bmcgetdeviceid+0xef/0x950 [ipmimsghandler] redobmcreg+0x52/0x60 [ipmimsghandler] processonework+0x1a7/0x360

Set intf->inshutdown on the outerrstarted path before invoking the lower driver's shutdown callback. This prevents later redobmcreg retries from using an interface whose lower driver state has been cleaned up, and applies the same shutdown state to other IPMI interfaces as well.

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

usb: gadget: ftcm: synchronize delayed setalt with teardown

The ftcm setalt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses ftcm private state and may complete the setup request after disconnect or function teardown has already moved on.

Cancel and drain the delayed setalt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancelworksync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcmdisable() can cancel the queued work and clean up immediately.

Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayedstatus while the worker is about to complete the control request.

Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcmdelayedsetalt+0x6c/0xef0

Call Trace: <TASK> dumpstacklvl+0x66/0xa0 printreport+0xce/0x630 ? tcmdelayedsetalt+0x6c/0xef0 ? srsoaliasreturnthunk+0x5/0xfbef5 ? virtaddrvalid+0x188/0x320 ? tcmdelayedsetalt+0x6c/0xef0 kasanreport+0xe0/0x110 ? tcmdelayedsetalt+0x6c/0xef0 tcmdelayedsetalt+0x6c/0xef0 ? pfxtcmdelayedsetalt+0x10/0x10 ? processonework+0x4cb/0xb90 ? rcuiswatching+0x20/0x50 ? tcmdelayedsetalt+0x9/0xef0 processonework+0x4d7/0xb90 ? pfxprocessonework+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? listaddvalidorreport+0x37/0xf0 ? pfxtcmdelayedsetalt+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 workerthread+0x2d8/0x570 ? pfxworkerthread+0x10/0x10 kthread+0x1ad/0x1f0 ? pfxkthread+0x10/0x10 retfromfork+0x3c9/0x540 ? pfxretfromfork+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? switchto+0x2e9/0x730 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 544: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasankmalloc+0x8f/0xa0 tcmalloc+0x68/0x180 usbgetfunction+0x36/0x60 configusbcfglink+0x125/0x1b0 configfssymlink+0x322/0x890 vfssymlink+0xc2/0x270 filenamesymlinkat+0x295/0x2f0 x64syssymlinkat+0x62/0x90 dosyscall64+0x115/0x6a0 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 661: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 kasanslabfree+0x43/0x70 kfree+0x2f9/0x530 configusbcfgunlink+0x173/0x1e0 configfsunlink+0x1fa/0x340 vfsunlink+0x15c/0x510 filenameunlinkat+0x2ba/0x450 x64sysunlinkat+0x63/0x90 dosyscall64+0x115/0x6a0 entrySYSCALL64afterhwframe+0x77/0x7f

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

sctp: fix NULL deref on untransmitted RECONF completion

sctpprocessstrresetoutreq(), sctpprocessstrresetaddstrmout() and sctpprocessstrresetresp() complete a pending stream reconfiguration request by stopping the reconf timer on the transport it was sent on:

t = asoc->strresetchunk->transport; if (timerdelete(&t->reconftimer)) sctptransportput(t);

chunk->transport is assigned by sctppacketappendchunk() when the chunk is appended to an outbound packet, and sctpoutqflushctrl() arms the reconf timer at that same point. A request already published in asoc->strresetchunk but not yet transmitted has neither, so completing it dereferences NULL.

Two ways to get there. sctpsendasconfdelip() sets asoc->srcoutofasocok without sending anything when the address being removed is the association's last one, and sctpoutqflushctrl() then leaves every non-ASCONF control chunk queued; as only sctpprocessasconfack() clears that flag, it persists. An unprivileged process that removes such an address and then asks for a stream reset panics the kernel from softirq. A peer needs neither ASCONF nor local help: sctpcmdinterpreter() uncorks the outqueue only once the whole packet has been processed, so a reply built while walking a RECONF chunk stays untransmitted for the rest of that walk, and one RECONF chunk carrying [Incoming SSN Reset Request, Outgoing SSN Reset Request, Response] -- or two RECONF chunks in one packet -- reaches the same dereference.

KASAN: null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef] RIP: 0010:timerdelete+0x67/0x110 Call Trace: <IRQ> sctpprocessstrresetaddstrmout (net/sctp/stream.c:832) sctpsfdoreconf (net/sctp/smstatefuns.c:4212) sctpdosm (net/sctp/smsideeffect.c:1172) sctpassocbhrcv (net/sctp/associola.c:1044) sctprcv (net/sctp/input.c:243) iplocaldeliver (net/ipv4/ipinput.c:262) processbacklog (net/core/dev.c:6680) </IRQ>

A response can only acknowledge a request that was actually sent, so do not match asoc->strresetchunk while chunk->transport is NULL. Guarding the lookup covers all three completion sites.

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

ipvs: avoid out-of-bounds write in ipvsnaticmp

Sashiko warns that local attacker can modify the packet while it is processed by IPVS. Some places read the IP ihl field multiple times which can cause out-of-bounds access. One such place is ipvsnaticmp where we can write after the validated area.

Fix it by providing ciph argument just like it is done for IPv6 and use ciph->len as offset to the embedded transport header.

Modify some IPv4 header checks by reading the ihl field only once.

drm/vmwgfx: fix guestmemorydirty bitfield clobbered as size

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

udp: fix potential use-after-free in tunnel segmentation

skbudptunnelsegment() gets the UDP header before ensuring the tunnel header is in the skb head. If the pull reallocates skb->head, the saved UDP header pointer is no longer valid.

Get the UDP header after the pull to avoid a potential use-after-free.

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

net: mpls: initialize rtmtos in mplsgetroute()

mplsgetroute() builds the RTMNEWROUTE reply to an RTMGETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (allocskb(NLMSGGOODSIZE, ...)). It sets every field of the header except rtmtos:

r = nlmsgdata(nlh); r->rtmfamily = AFMPLS; r->rtmdstlen = 20; r->rtmsrclen = 0; r->rtmtable = RTTABLEMAIN; r->rtmtype = RTNUNICAST; r->rtmscope = RTSCOPEUNIVERSE; r->rtmprotocol = rt->rtprotocol; r->rtmflags = 0;

struct rtmsg has no padding, so the one uninitialised byte rtmtos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mplsdumproute(), which fills the very same header and does set rtmtos = 0.

Initialize rtmtos to 0, matching mplsdumproute().

Reproduced with KMSAN by adding an MPLS route and issuing a non-RTMFFIBMATCH RTMGETROUTE for its label:

BUG: KMSAN: kernel-infoleak in copytoiter+0x36c/0x33f0 copytoiter+0x36c/0x33f0 skbdatagramiter+0x196/0x12c0 skbcopydatagramiter+0x5b/0x210 netlinkrecvmsg+0x37b/0xef0 ... Uninit was created at: allocskb+0x8ca/0x10e0 mplsgetroute+0x1280/0x3a40 rtnetlinkrcvmsg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized

(byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtmtos)

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

power: supply: lp8727: fix use-after-free in lp8727releaseirq()

lp8727isrfunc(), the threaded IRQ handler, is the only caller that arms pchg->work via scheduledelayedwork(). lp8727releaseirq() currently cancels the work before freeing the IRQ, so an IRQ delivered in between can re-arm the work through the threaded handler. After .remove returns the devm layer frees pchg while lp8727delayedfunc() may still run and dereference it.

Free the IRQ first so the threaded handler is quiesced and can no longer queue work, then cancel the delayed work to drain the final generation.

This issue was found by an in-house static analysis tool.

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

SUNRPC: svcauthgss: enforce krb5 token minimum length

svcauthgssunwrappriv() validates only an upper bound on the wire-supplied opaque length before handing the buffer to gssunwrap():

if (len > xdrstreamremaining(xdr)) goto unwrapfailed; offset = xdrstreampos(xdr); ... majstat = gssunwrap(ctx, offset, offset + len, buf);

The wire value len flows unchanged as the upper bound into the krb5 unwrap path, so a len in [0, 16] passes this check and is handed to gssunwrap(). For a krb5 v2 context that lands in gsskrb5unwrapv2(), which reads the 16-byte RFC 4121 token header fields at ptr+4 and ptr+6 and then calls rotateleft() before any integrity check. With a sub-header length the header reads run past the token, and rotateleft()'s shift %= buf->len path can divide by zero when buf->len has been driven to zero by the truncated token. A header-only token (len == 16) is equally invalid: with a non-zero RRC field and the opaque blob ending at the XDR buffer boundary, rotateleft() builds a zero-length subbuffer, reaching the same division.

Reject the token at the server entry point before it reaches the krb5 unwrap core. A valid sealed RFC 4121 token must contain the 16-byte header plus at least some encrypted payload.

Fix by adding a minimum-length check immediately after the existing upper-bound check:

if (len <= GSSKRB5TOKHDRLEN) goto unwrapfailed;

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

wifi: brcmfmac: Fix memory leak in brcmfsdioreadcontrol()

The memory allocated for buf is not freed in some of the error paths in brcmfsdioreadcontrol(). Fix that by adding vfree() calls.

[arend: rework as suggested by Johannes]

drm/vmwgfx: bound DMA command body size against suffix pointer

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

net/smc: fix socket use-after-free during link group termination

smclgrterminate() drops connslock after finding a connection in lgr->connsall, but before taking a reference on its socket. The connection is embedded in the socket, and its registration reference protects it only while the connection remains in the tree.

A concurrent close can unregister the connection and drop that reference, freeing the socket before the termination worker reaches sockhold().

The race is reachable when close overlaps link group termination. Local stress testing reproduced the use-after-free and KASAN reported:

BUG: KASAN: slab-use-after-free in smclgrterminate.part.0 [smc] Write of size 4 by task kworker/3:3 Workqueue: events smclgrterminatework [smc] smclgrterminate.part.0 [smc]

The socket was allocated by smccreate(), freed through slabfreeafterrcudebug(), and was followed by:

refcountt: addition on 0; use-after-free. smclgrterminate.part.0 [smc]

Take the socket reference while connslock still protects the tree entry. The unregister path then cannot drop the last reference until termination has finished using the socket.

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

wifi: ath6kl: fix use-after-free in aggrresetstate()

The aggrresetstate() function uses timerdelete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggrmoduledestroy().

If the timer callback (aggrtimeout) is executing when aggrresetstate() is called, the callback will continue to access aggrconn fields like rxtid[] and stat[] which may be freed immediately after by kfree(aggrinfo->aggrconn) in aggrmoduledestroy().

Additionally, the timer callback can re-arm itself via modtimer() while aggrresetstate() is running, creating a more complex race condition.

Use timerdeletesync() instead to ensure any running timer callback has completed before returning.

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

usb: musb: omap2430: Do not put borrowed ofnode in probe

omap2430probe() stores pdev->dev.ofnode in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it.

The success and error paths nevertheless call ofnodeput(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.ofnode with an unbalanced reference count.

Do not put the borrowed platform device node from omap2430probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.

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

net/smc: fix use-after-free in smcrxpipebufrelease()

smcrxsplice() hands RMB pages to a pipe and takes a socket reference per entry so the smcsock stays alive until the reader finishes. The connection does not: a concurrent close runs smcconnfree(), which releases the receive buffer back to the link group pool.

smcrxpipebufrelease() tests skstate before taking the socket lock. The state can change between the test and the lock, and smcrxupdatecons() then dereferences conn->rmbdesc and walks conn->lgr, which smcconnfree() has already released. On the isregerr path smcrbufunuse() frees the descriptor outright, so this is a use-after-free.

Take the socket lock first and test conn->freed instead. smcconnfree() sets that flag before releasing anything, and every caller holds the socket lock. The two paths exclude each other: either the pipe release runs first with everything valid, or it sees the flag and skips the update.

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

net/ncsi: fix heap OOB read in NCSICMDSENDCMD payload length

ncsisendcmdnl() takes the number of bytes to copy from the attacker-controlled ncsipkthdr.length field of the in-band packet header, while the source buffer is the NCSIATTRDATA netlink attribute whose readable size is nlalen() - sizeof(ncsipkthdr). The two length sources are never cross-checked: only nlalen() >= sizeof(struct ncsipkthdr) is enforced.

With hdr->length set larger than the attribute payload (up to 65535 against at most 2032 readable bytes), ncsicmdhandleroem() copies past the end of the netlink attribute buffer with unsafememcpy(), leaking up to ~64KB of kernel heap memory into the transmitted NCSI command packet. The destination skb is sized by the declared payload, so the write side does not overflow - this is a pure OOB read / information leak, reachable with CAPNETADMIN on systems with a registered NCSI device (e.g. OpenBMC on Aspeed BMC SoCs, where NETNCSI=y is standard).

Reject commands whose declared payload extends past the end of the data attribute.

The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.

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

sctp: close UDP tunnel sockets during netns teardown

procsctpdoudpport() starts per-net SCTP UDP tunneling sockets when net.sctp.udpport is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed.

Close the UDP tunnel sockets from sctpctrlsockexit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.

drm/vmwgfx: reject DXBINDQUERY without a DX context