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

nvmet-auth: fix out-of-bounds write in nvmetauthchallenge()

nvmetauthchallenge() receives its output buffer as a void pointer. sizeof(d) therefore evaluates to one with GCC and undercounts the fixed challenge header by 15 bytes. A short AUTHRECEIVE buffer can pass the check before the challenge is copied past the end of its allocation.

Use the typed challenge pointer when calculating the response size.

BUG: KASAN: slab-out-of-bounds in nvmetexecuteauthreceive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569) Write of size 32 by task kworker/1:1H/64 Workqueue: nvmettcpwq nvmettcpiowork Call Trace: nvmetexecuteauthreceive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569) nvmettcptryrecvpdu (drivers/nvme/target/tcp.c:1119 drivers/nvme/target/tcp.c:1243) nvmettcpiowork (drivers/nvme/target/tcp.c:1350 drivers/nvme/target/tcp.c:1382 drivers/nvme/target/tcp.c:1445) processonework (kernel/workqueue.c:3322) workerthread (kernel/workqueue.c:3405 kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245) The buggy address is located 16 bytes inside of allocated 33-byte region [ffff888000554e80, ffff888000554ea1) Kernel panic - not syncing: KASAN: paniconwarn set ...

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

soc: xilinx: Shutdown and free rx mailbox channel

A mbox rx channel is requested using mboxrequestchannelbyname() in probe. In remove callback, the rx mailbox channel is cleaned up when the rxchan is NULL due to incorrect condition check. The mailbox channel is not shutdown and it can receive messages even after the device removal. This leads to use after free. Also the channel resources are not freed. Fix this by checking the rxchan correctly.

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

media: atomisp: gc2235: fix UAF and memory leak

gc2235probe() handles its error paths incorrectly.

If mediaentitypadsinit() fails, gc2235remove() is called, which tears down the subdev and frees dev, but then still falls through to atomispregisteri2cmodule(). This results in use-after-free.

If atomispregisteri2cmodule() fails, the media entity and control handler are left initialized and dev is leaked.

gc2235remove() unconditionally calls mediaentitycleanup() and v4l2ctrlhandlerfree(), but these are not initialized at every error path in gc2235probe().

Replace gc2235remove() calls in the probe error paths with explicit unwind labels that free only the resources initialized at each point of failure, in reverse order of initialization.

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

RDMA/siw: Fix endpoint/socket association handling

Disassociating a socket from an endpoint via siwsocketdisassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within.

This fixes a:

BUG: KASAN: slab-use-after-free in siwcmworkhandler (drivers/infiniband/sw/siw/siwcm.c:1053 drivers/infiniband/sw/siw/siwcm.c:1075)

which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.

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

nvmet-auth: reject short AUTHRECEIVE buffers

nvmetexecuteauthreceive() trusts the AUTHRECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmetauthsuccess1() and nvmetauthfailure1() write past the allocation; both only WARNON the short length and then format the message anyway.

Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTHRECEIVE allocation length.

Compute the minimum response length for the current DH-HMAC-CHAP step in nvmetauthreceivedatalen() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmetexecuteauthreceive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmfauthdhchapsuccess1data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmetauthchallenge().

This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.

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

svcrdma: bound check rqpages index in inline path

svcrdmacopyinlinerange indexed rqstp->rqpages[rccurpage] without verifying rccurpage stays within the allocated page array. Add guards before the first use and after advancing to a new page.

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

RDMA/rtrs-srv: Fix integer underflow in processread and processwrite

usrlen is read from a network-supplied message field (le16tocpu) and used to compute datalen = off - usrlen without validating that usrlen <= off. A malicious RDMA client can send usrlen > off causing an integer underflow, resulting in datalen wrapping to a huge sizet value which is then passed to the rdmaev callback as a memory length, leading to out-of-bounds memory access.

Fix by reading and validating usrlen <= off before rtrssrvgetopsids() in both processread() and processwrite(), ensuring the early return path acquires no reference and has no resource leak.

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

net: mana: Validate the packet length reported by the NIC

Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.

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

s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs

There is a wrong upper limit check for the domain value when an EP11 CPRB is processed for sending to a crypto card. This check is only active on custom device nodes but may lead to access heap memory behind perms->adm when an administrative CPRB is sent. Add correct limit (APDOMAINS = 256) checking to fix this.

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

wifi: mwifiex: bound the pairwise-cipher OUI walk to the IE length

mwifiexsearchouiinie() reads a pairwise-cipher (PTK) count from a beacon/probe-response RSN or WPA information element and then walks that many 4-byte OUIs, comparing each with memcmp(). The count comes straight from the (attacker-supplied) IE and is never checked against the element's own length, and the callers admit the element on elementid alone (hasieeehdr() / hasvendorhdr(), no length check). A crafted RSN/WPA IE with a large pairwise count therefore makes the walk read up to 255 4 bytes past the element -- an out-of-bounds read of the kmemdup()'d beacon buffer, reachable from any AP whose beacon/probe response is processed during scan-result parsing.

Pass the number of IE bytes available at the OUI list and bound the walk to the element. Keep the length signed and reject a negative value before any unsigned arithmetic, so a small or zero IE length cannot underflow to a large sizet and defeat the bound.

Found by 0sec automated security-research tooling (https://0sec.ai).

ftrace: Add global mutex to serialize traceparser access

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

sctp: fix use-after-free of cached ASCONF chunk

addiplastasconf caches the outstanding outbound ASCONF chunk. The normal ASCONF-ACK completion path releases the chunk and clears the pointer.

However, sctpasconfqueueteardown() releases the cached chunk without clearing addiplastasconf. During peer restart handling, sctpsfdodupcooka() queues SCTPCMDPURGEASCONFQUEUE, which invokes sctpasconfqueueteardown() while the association remains alive and leaves the pointer dangling.

A delayed authenticated ASCONF-ACK can then reach sctpsfdoasconfack(), which accesses the stale chunk and passes it to sctpprocessasconfack(), causing a use-after-free and a second release.

Clearing the pointer exposes a race with T4 expiry. Peer restart handling queues the timer stop before the purge, but SCTPCMDTIMERSTOP uses timerdelete(), which does not wait for a callback already running on another CPU. Such a callback can reach sctpsft4timerexpire() after the purge and dereference NULL.

Clear addiplastasconf after releasing the cached chunk, and make sctpsft4timerexpire() consume a stale T4 expiry if no outstanding ASCONF remains.

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

smb: client: Fix use-after-free in cifstryaddingchannels()

cifstryaddingchannels() takes a temporary reference to an interface before dropping ifacelock. If cifssesaddchannel() fails, it drops that reference and then increments iface->weightfulfilled.

A concurrent interface list refresh can remove the list reference while channel creation is in progress. In that case, the failure-path krefput() releases the last reference and frees iface. Updating weightfulfilled afterward then accesses freed memory.

Increment weightfulfilled before dropping the temporary reference, keeping iface alive for the final access.

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

NFSv4: remove callback IDR entry on client allocation failure

nfs4allocclient() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfsclient directly with nfsfreeclient(). That bypasses nfsputclient(), which is where the callback IDR entry is removed during normal teardown.

A failed allocation can therefore leave cbidentidr pointing at a freed nfsclient. A later NFSv4.0 callback lookup by cbident would find the stale pointer and take a reference to it.

Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client.

This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection.

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

netfilter: flowtable: publish GC-visible tuple last

nfflowtableiterate() only treats original-direction tuple nodes as owning entries. Publishing the original node first lets GC observe and free a flow while flowoffloadadd() is still inserting the reply node. Publish the reply node first and the original node last so GC never sees a partially installed flow.

KASAN can trigger slab-use-after-free read and write reports in the flowtable/rhashtable path (rhtdeferredworker, jhash, flowoffloaddel, flowoffloadlookup, etc.).

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

wifi: wlcore: release runtime PM ref on regdomain config failure

wlcoreregdomainconfig() gets a runtime PM reference before sending the regulatory-domain command. When wlcorecmdregdomainconfiglocked() fails, the function queues recovery and returns without dropping that reference.

Release the reference after handling the command result so both success and failure paths balance the preceding pmruntimeresumeandget(). The recovery worker takes a separate runtime PM reference and cannot release the reference held here.

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

net: enetc: check the number of BDs needed for xdpframe

The size of xdpredirectarr array is ENETCMAXSKBFRAGS. However, the number of fragments contained in xdpframe may be greater than or equal to ENETCMAXSKBFRAGS, which will cause the access to xdpredirectarr to be out of bounds.

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

Input: cyttsp5 - clamp the HID report size before memcpy

The size field comes from the device and is used as the memcpy() length into responsebuf, which is CYMAXINPUT bytes.

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

md/raid10: fix stilldegraded being inverted in raid10syncrequest()

Commit fe6a19d40ceb ("md/md-bitmap: merge mdbitmapstartsync() into bitmapoperations") converted stilldegraded from int to bool, but inverted the assignment in the loop that checks whether the array will still be degraded after the current device is recovered: "stilldegraded = 1" became "stilldegraded = false".

As a result, recovering a device while another mirror is still missing calls mdbitmapstartsync() with degraded == false, which clears bitmap bits that the still-missing device needs. When that device is re-added, its bitmap-based recovery finds the bits already cleared and skips every region written while the array was degraded, so it is marked Insync while holding stale data: silent corruption.

Reproducer (raid10 near=2, 4 disks, internal bitmap): - fail and remove one disk of each mirror pair - write to the degraded array - re-add both disks and let recovery finish - "check" reports mismatchcnt=262272 after 256 MiB of degraded writes and file contents differ; the second disk's "recovery" completes in milliseconds because everything is skipped

The same conversion in raid1 got it right (stilldegraded = true). Restore the correct value.

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

SUNRPC: Zero rpcgsswirecred at svcauthgssdecodecredbody() entry

svcauthgssdecodecredbody() writes the caller's rpcgsswirecred field by field and assigns gcctx.len only on the success tail. The caller storage is svcdata->clcred, which lives in the per-svcrqst gsssvcdata and is reused across requests. Early decode failures leave partially decoded state mixed with residue from the prior request.

The trailing bodylen tightness check is the sharpest case: xdrstreamdecodeopaqueinline() has already written gcctx.data with a borrowed inline pointer into the current request's XDR pages, but gcctx.len retains its prior value. Once the request pages are released the pooled clcred carries a dangling pointer paired with a stale length.

Zero the caller's rpcgsswirecred at function entry so that every early-return path leaves a deterministic all-zero cred. On the trailing tightness-check path, gcctx.len is now zero instead of stale, which neuters length-driven consumers such as gsssvcsearchbyctx() that would otherwise walk the dangling data pointer.

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

wifi: p54: validate curve data length in the calibration curve converters

p54convertrev0() and p54convertrev1() read calibration curve data from the device-supplied EEPROM entry using channel and points-per-channel counts taken verbatim from that same entry, so an entry that declares more data than it carries drives an out-of-bounds read past the EEPROM buffer (verified with a KASAN reproducer of the conversion loop). The sibling converters p54convertoutputlimits() and p54convertdb() already validate their counts against the entry length; this path was missed.

Reject the entry when the counts do not fit in the entry data.

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

nvmet-rdma: handle inline data with a nonzero offset

nvmetrdmauseinlinesg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inlinedatasize, but the mapping still assumes the data begins in the first inline page:

sg->offset = off; sg->length = mint(int, len, PAGESIZE - off);

When a port is configured with inlinedatasize > PAGESIZE (settable up to max(SZ16K, PAGESIZE)), an offset in (PAGESIZE, inlinedatasize] makes "PAGESIZE - off" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. numpages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist.

Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from pageoff + len. Because the request scatterlist may now start at inlinesg[pageidx] rather than inlinesg[0], generalize the inline-SGL identity test in nvmetrdmareleasersp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmetreqfreesgls() frees an inline page (and warns in freelargekmalloc()).

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

NFSD: Prevent client use-after-free during admin state revocation

A stateid holds only a bare pointer to its nfs4client; a stateid reference does not pin it. The client survives only because destroyclient() drains its stateids before freeclient() runs.

nfsd4revokestates() drops nn->clientlock across revokeonestid(), which dereferences the client to revoke a stateid and read clp->clminorversion. A teardown racing the dropped lock can free the client first.

Pinning clrpcusers under clientlock blocks the DESTROYCLIENTID and EXCHANGEID teardown, which refuses while clrpcusers is non-zero. forceexpireclient() ignores it: once its wait for clrpcusers to reach zero has passed, a later pin goes unnoticed.

Under clientlock, skip a client whose cltime is already zero -- forceexpireclient() clears it there before waiting -- otherwise pin clrpcusers before dropping the lock. The walk then either sees the expiry and skips, or pins in time for that wait to cover the revoke.

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

mmc: sdhci-of-aspeed: Remove children before releasing SDC resources

Probe failure and removal leave SDHCI child devices registered after the parent clock and managed resources are released.

Unregister the OF children in reverse order before disabling the parent clock on both paths. Use ofplatformdevicedestroy() because manual child creation does not set the flag required by ofplatformdepopulate().

This issue was identified during our ongoing static-analysis research while reviewing kernel code.

ASoC: codecs: rt712-sdca-dmic: fix uninitialized streamconfig->type

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

nvme-multipath: fix flex array size in struct nvmenshead

struct nvmenshead contains a flexible array member, currentpath[], which is indexed using the NUMA node ID: head->currentpath[numanodeid()]

The structure is currently allocated as: size = sizeof(struct nvmenshead) + (numpossiblenodes() sizeof(struct nvmens )); head = kzalloc(size, GFPKERNEL);

This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. numpossiblenodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc.

On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s):

That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: numpossiblenodes() = 6

So memory is allocated for only 6 entries in currentpath[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->currentpath[8] or head->currentpath[252] goes out of bounds, leading to the following KASAN splat:

================================================================== BUG: KASAN: slab-out-of-bounds in nvmempathrevalidatepaths+0x22c/0x290 [nvmecore] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997

CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async asyncrunentryfn Call Trace: [c000200037fa7510] [c0000000021c23d4] dumpstacklvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] printreport+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasanreport+0x108/0x220 [c000200037fa7740] [c0000000009fff48] asanstore8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvmempathrevalidatepaths+0x22c/0x290 [nvmecore] [c000200037fa7800] [c008000018e6556c] nvmeupdatensinfo+0x4a4/0x5e0 [nvmecore] [c000200037fa7a50] [c008000018e66270] nvmeallocns+0x6d8/0x1a70 [nvmecore] [c000200037fa7c20] [c008000018e679fc] nvmescanns+0x3f4/0x630 [nvmecore] [c000200037fa7d10] [c00000000031f22c] asyncrunentryfn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] processonework+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] workerthread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] startkernelthread+0x14/0x18

Allocated by task 1997 on cpu 1 at 35.928317s:

The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8)

The buggy address belongs to the physical page:

Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ==================================================================

Fix this by allocating the flexible array using nrnodeids instead of numpossiblenodes(). Since nrnodeids represents the maximum possible NUMA node IDs, indexing currentpath[] using numanodeid() becomes safe even on systems with sparse node IDs.

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

iommu/arm-smmu-v3-iommufd: Require exactly one Stream ID for a vDEVICE

armvsmmuvsidtosid() maps a guest's vSID to a single physical Stream ID taken from master->streams[0], assuming a device has exactly one stream. A device with several streams gets only its first one mapped, so a guest vSID invalidation cannot reach the others' ATC and IOTLB entries; a device with none makes master->streams a ZEROSIZEPTR, read out of bounds.

Add an armvsmmuvdeviceinit() op to reject the vDEVICE with -EOPNOTSUPP when master->numstreams is not one, rather than mapping it silently.

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

net: wwan: t7xx: validate the netif index in t7xxccmnirecvskb()

The netif index carried in the DPMAIF PIT header is five bits wide, but ccmniinst[] only has room for NICDEVMAX (21) entries. t7xxccmnirecvskb() indexes the array without a bounds check, so indexes 21 to 31 read past it. The out-of-bounds value lands in the callback table that follows the array, which is never NULL, so the existing !ccmni check does not catch it and the driver dereferences whatever sits there as a struct t7xxccmni.

Drop the skb when the index is out of range.

Verified in a QEMU guest with a fault injector setting the netif index to 25: the unpatched driver reads a value past ccmniinst[], which lands in the callback table, and dereferences it far enough to queue the skb. With this check the packet is dropped. Well-formed traffic on index 0 is unaffected.

Changes in v2: none.

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

tipc: restrict socket queue dumps in enqueue tracepoints

tipcskenqueue() runs with sk->sklock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging skreceivequeue.

KASAN reported:

CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x76/0xa0 lib/dumpstack.c:123 printreport+0xce/0x5b0 mm/kasan/report.c:482 kasanreport+0xc6/0x100 mm/kasan/report.c:597 asanreportload4noabort+0x14/0x30 mm/kasan/reportgeneric.c:380 tipcskbdump+0x1327/0x16f0 net/tipc/trace.c:73 tipclistdump+0x208/0x2e0 net/tipc/trace.c:187 tipcskdump+0xaf6/0xd60 net/tipc/socket.c:3996 traceeventraweventtipcskclass+0x312/0x5a0 net/tipc/trace.h:188 tipcskrcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipcnodexmit+0x1c3/0x1440 net/tipc/node.c:1689 tipcsendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipcsendmsg+0x52/0x80 net/tipc/socket.c:1400 socksendmsg+0x2f6/0x3e0 net/socket.c:825 splicetosocket+0x7f9/0x1010 fs/splice.c:884 dosplice+0xe21/0x2330 fs/splice.c:936 dosplice+0x153/0x260 fs/splice.c:1431 x64syssplice+0x150/0x230 fs/splice.c:1616 x64syscall+0xeb5/0x2790 arch/x86/entry/syscall64.c:41 dosyscall64+0xf3/0x620 arch/x86/entry/syscall64.c:63 entrySYSCALL64afterhwframe+0x76/0x7e arch/x86/entry/entry64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIGRAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 </TASK>

The TIPCDUMPALL tracepoints in tipcskenqueue() also dump skreceivequeue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPCDUMPSKBKLGQ, which matches the queue protected by the held spinlock.

Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.

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

nvme: fix FDP fdpcidx bounds check

The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdpidx when it equals n (i.e. NUMFDPC + 1).