bus: mhi: ep: Update read pointer only after buffer is written

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

RDMA/rtrs: Add missing deinit() call

A warning is triggered when repeatedly connecting and disconnecting the rnbd: listadd corruption. prev->next should be next (ffff88800b13e480), but was ffff88801ecd1338. (prev=ffff88801ecd1340). WARNING: CPU: 1 PID: 36562 at lib/listdebug.c:32 listaddvalidorreport+0x7f/0xa0 Workqueue: ibcm cmworkhandler [ibcm] RIP: 0010:listaddvalidorreport+0x7f/0xa0 ? listaddvalidorreport+0x7f/0xa0 ibregistereventhandler+0x65/0x93 [ibcore] rtrssrvibdevinit+0x29/0x30 [rtrsserver] rtrsibdevfindoradd+0x124/0x1d0 [rtrscore] allocpath+0x46c/0x680 [rtrsserver] ? rtrsrdmaconnect+0xa6/0x2d0 [rtrsserver] ? rcuiswatching+0xd/0x40 ? mutexlock+0x312/0xcf0 ? getorcreatesrv+0xad/0x310 [rtrsserver] ? rtrsrdmaconnect+0xa6/0x2d0 [rtrsserver] rtrsrdmaconnect+0x23c/0x2d0 [rtrsserver] ? lockrelease+0x1b1/0x2d0 cmacmeventhandler+0x4a/0x1a0 [rdmacm] cmaibreqhandler+0x3a0/0x7e0 [rdmacm] cmprocesswork+0x28/0x1a0 [ibcm] ? rawspinunlockirq+0x2f/0x50 cmreqhandler+0x618/0xa60 [ibcm] cmworkhandler+0x71/0x520 [ibcm]

Commit 667db86bcbe8 ("RDMA/rtrs: Register ib event handler") introduced a new element .deinit but never used it at all. Fix it by invoking the deinit() to appropriately unregister the IB event handler.

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

RDMA/rxe: Fix the warning "rxecleanup+0x12c/0x170 [rdmarxe]"

The Call Trace is as below: " <TASK> ? showregs.cold+0x1a/0x1f ? rxecleanup+0x12c/0x170 [rdmarxe] ? warn+0x84/0xd0 ? rxecleanup+0x12c/0x170 [rdmarxe] ? reportbug+0x105/0x180 ? handlebug+0x46/0x80 ? excinvalidop+0x19/0x70 ? asmexcinvalidop+0x1b/0x20 ? rxecleanup+0x12c/0x170 [rdmarxe] ? rxecleanup+0x124/0x170 [rdmarxe] rxedestroyqp.cold+0x24/0x29 [rdmarxe] ibdestroyqpuser+0x118/0x190 [ibcore] rdmadestroyqp.cold+0x43/0x5e [rdmacm] rtrscqqpdestroy.cold+0x1d/0x2b [rtrscore] rtrssrvclosework.cold+0x1b/0x31 [rtrsserver] processonework+0x21d/0x3f0 workerthread+0x4a/0x3c0 ? processonework+0x3f0/0x3f0 kthread+0xf0/0x120 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x22/0x30 </TASK> " When too many rdma resources are allocated, rxe needs more time to handle these rdma resources. Sometimes with the current timeout, rxe can not release the rdma resources correctly.

Compared with other rdma drivers, a bigger timeout is used.

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

nvmet: Fix crash when a namespace is disabled

The namespace percpu counter protects pending I/O, and we can only safely diable the namespace once the counter drop to zero. Otherwise we end up with a crash when running blktests/nvme/058 (eg for loop transport):

[ 2352.930426] [ T53909] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI [ 2352.930431] [ T53909] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] [ 2352.930434] [ T53909] CPU: 3 UID: 0 PID: 53909 Comm: kworker/u16:5 Tainted: G W 6.13.0-rc6 #232 [ 2352.930438] [ T53909] Tainted: [W]=WARN [ 2352.930440] [ T53909] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [ 2352.930443] [ T53909] Workqueue: nvmet-wq nvmeloopexecutework [nvmeloop] [ 2352.930449] [ T53909] RIP: 0010:blkcgsetioprio+0x44/0x180

as the queue is already torn down when calling submitbio();

So we need to init the percpu counter in nvmetnsenable(), and wait for it to drop to zero in nvmetnsdisable() to avoid having I/O pending after the namespace has been disabled.

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

netmem: prevent TX of unreadable skbs

Currently on stable trees we have support for netmem/devmem RX but not TX. It is not safe to forward/redirect an RX unreadable netmem packet into the device's TX path, as the device may call dma-mapping APIs on dma addrs that should not be passed to it.

Fix this by preventing the xmit of unreadable skbs.

Tested by configuring tc redirect:

sudo tc qdisc add dev eth1 ingress sudo tc filter add dev eth1 ingress protocol ip prio 1 flower ipproto \ tcp srcip 192.168.1.12 action mirred egress redirect dev eth1

Before, I see unreadable skbs in the driver's TX path passed to dma mapping APIs.

After, I don't see unreadable skbs in the driver's TX path passed to dma mapping APIs.

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

RDMA/erdma: Prevent use-after-free in erdmaacceptnewconn()

After the erdmacepput(newcep) being called, newcep will be freed, and the following dereference will cause a UAF problem. Fix this issue.

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

Revert "smb: client: fix TCP timers deadlock after rmmod"

This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.

Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is mentioned as CVE-2024-54680, but is actually did not fix anything; The issue can be reproduced on top of it. [0]

Also, it reverted the change by commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") and introduced a real issue by reviving the kernel TCP socket.

When a reconnect happens for a CIFS connection, the socket state transitions to FINWAIT1. Then, inetcskclearxmittimerssync() in tcpclose() stops all timers for the socket.

If an incoming FIN packet is lost, the socket will stay at FINWAIT1 forever, and such sockets could be leaked up to net.ipv4.tcpmaxorphans.

Usually, FIN can be retransmitted by the peer, but if the peer aborts the connection, the issue comes into reality.

I warned about this privately by pointing out the exact report [1], but the bogus fix was finally merged.

So, we should not stop the timers to finally kill the connection on our side in that case, meaning we must not use a kernel socket for TCP whose sk->sknetrefcnt is 0.

The kernel socket does not have a reference to its netns to make it possible to tear down netns without cleaning up every resource in it.

For example, tunnel devices use a UDP socket internally, but we can destroy netns without removing such devices and let it complete during exit. Otherwise, netns would be leaked when the last application died.

However, this is problematic for TCP sockets because TCP has timers to close the connection gracefully even after the socket is close()d. The lifetime of the socket and its netns is different from the lifetime of the underlying connection.

If the socket user does not maintain the netns lifetime, the timer could be fired after the socket is close()d and its netns is freed up, resulting in use-after-free.

Actually, we have seen so many similar issues and converted such sockets to have a reference to netns.

That's why I converted the CIFS client socket to have a reference to netns (sk->sknetrefcnt == 1), which is somehow mentioned as out-of-scope of CIFS and technically wrong in e9f2517a3e18, but is in-scope and right fix.

Regarding the LOCKDEP issue, we can prevent the module unload by bumping the module refcount when switching the LOCKDDEP key in socklockinitclassandname(). [2]

For a while, let's revert the bogus fix.

Note that now we can use sknetrefcntupgrade() for the socket conversion, but I'll do so later separately to make backport easy.

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

smb: client: fix UAF in decryption with multichannel

After commit f7025d861694 ("smb: client: allocate crypto only for primary server") and commit b0abcd65ec54 ("smb: client: fix UAF in async decryption"), the channels started reusing AEAD TFM from primary channel to perform synchronous decryption, but that can't done as there could be multiple cifsd threads (one per channel) simultaneously accessing it to perform decryption.

This fixes the following KASAN splat when running fstest generic/249 with 'vers=3.1.1,multichannel,maxchannels=4,seal' against Windows Server 2022:

BUG: KASAN: slab-use-after-free in gf128mul4klle+0xba/0x110 Read of size 8 at addr ffff8881046c18a0 by task cifsd/986 CPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x5d/0x80 printreport+0x156/0x528 ? gf128mul4klle+0xba/0x110 ? virtaddrvalid+0x145/0x300 ? physaddr+0x46/0x90 ? gf128mul4klle+0xba/0x110 kasanreport+0xdf/0x1a0 ? gf128mul4klle+0xba/0x110 gf128mul4klle+0xba/0x110 ghashupdate+0x189/0x210 shashahashupdate+0x295/0x370 ? pfxshashahashupdate+0x10/0x10 ? pfxshashahashupdate+0x10/0x10 ? pfxextractitertosg+0x10/0x10 ? kmalloclargenode+0x10e/0x180 ? asanmemset+0x23/0x50 cryptoahashupdate+0x3c/0xc0 gcmhashassocremaincontinue+0x93/0xc0 cryptmessage+0xe09/0xec0 [cifs] ? pfxcryptmessage+0x10/0x10 [cifs] ? rawspinunlock+0x23/0x40 ? pfxcifsreadvfromsocket+0x10/0x10 [cifs] decryptrawdata+0x229/0x380 [cifs] ? pfxdecryptrawdata+0x10/0x10 [cifs] ? pfxcifsreaditerfromsocket+0x10/0x10 [cifs] smb3receivetransform+0x837/0xc80 [cifs] ? pfxsmb3receivetransform+0x10/0x10 [cifs] ? pfxmightresched+0x10/0x10 ? pfxsmb3istransformhdr+0x10/0x10 [cifs] cifsdemultiplexthread+0x692/0x1570 [cifs] ? pfxcifsdemultiplexthread+0x10/0x10 [cifs] ? rcuiswatching+0x20/0x50 ? rculockdepcurrentcpuonline+0x62/0xb0 ? findheldlock+0x32/0x90 ? kvmschedclockread+0x11/0x20 ? localclocknoinstr+0xd/0xd0 ? traceirqenable.constprop.0+0xa8/0xe0 ? pfxcifsdemultiplexthread+0x10/0x10 [cifs] kthread+0x1fe/0x380 ? kthread+0x10f/0x380 ? pfxkthread+0x10/0x10 ? localclocknoinstr+0xd/0xd0 ? retfromfork+0x1b/0x60 ? localclock+0x15/0x30 ? lockrelease+0x29b/0x390 ? rcuiswatching+0x20/0x50 ? pfxkthread+0x10/0x10 retfromfork+0x31/0x60 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

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

net: use sockgenput() when skstate is TCPTIMEWAIT

It is possible for a pointer of type struct inettimewaitsock to be returned from the functions inetlookupestablished() and inet6lookupestablished(). This can cause a crash when the returned pointer is of type struct inettimewaitsock and sockput() is called on it. The following is a crash call stack that shows sk->skwmemalloc being accessed in skfree() during the call to sockput() on a struct inettimewaitsock pointer. To avoid this issue, use sockgenput() instead of sockput() when sk->skstate is TCPTIMEWAIT.

mrdump.ko ipanic() + 120 vmlinux notifiercallchain(nrtocall=-1, nrcalls=0) + 132 vmlinux atomicnotifiercallchain(val=0) + 56 vmlinux panic() + 344 vmlinux addtaint() + 164 vmlinux endreport() + 136 vmlinux kasanreport(size=0) + 236 vmlinux reporttagfault() + 16 vmlinux dotagrecovery() + 16 vmlinux dokernelfault() + 88 vmlinux dobadarea() + 28 vmlinux dotagcheckfault() + 60 vmlinux domemabort() + 80 vmlinux el1abort() + 56 vmlinux el1h64synchandler() + 124 vmlinux > 0xFFFFFFC080011294() vmlinux lseatomicfetchaddrelease(v=0xF2FFFF82A896087C) vmlinux lseatomicfetchsubrelease(v=0xF2FFFF82A896087C) vmlinux archatomicfetchsubrelease(i=1, v=0xF2FFFF82A896087C) + 8 vmlinux rawatomicfetchsubrelease(i=1, v=0xF2FFFF82A896087C) + 8 vmlinux atomicfetchsubrelease(i=1, v=0xF2FFFF82A896087C) + 8 vmlinux refcountsubandtest(i=1, r=0xF2FFFF82A896087C, oldp=0) + 8 vmlinux refcountdecandtest(r=0xF2FFFF82A896087C, oldp=0) + 8 vmlinux refcountdecandtest(r=0xF2FFFF82A896087C) + 8 vmlinux skfree(sk=0xF2FFFF82A8960700) + 28 vmlinux sockput() + 48 vmlinux tcp6checkfraglistgro() + 236 vmlinux tcp6groreceive() + 624 vmlinux ipv6groreceive() + 912 vmlinux devgroreceive() + 1116 vmlinux napigroreceive() + 196 ccmni.ko ccmnirxcallback() + 208 ccmni.ko ccmniqueuerecvskb() + 388 cccidpmaif.ko dpmaifrxqpushthread() + 1088 vmlinux kthread() + 268 vmlinux 0xFFFFFFC08001F30C()

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

netfs: Fix oops in write-retry from mis-resetting the subreq iterator

Fix the resetting of the subrequest iterator in netfsretrywritestream() to use the iterator-reset function as the iterator may have been shortened by a previous retry. In such a case, the amount of data to be written by the subrequest is not "subreq->len" but "subreq->len - subreq->transferred".

Without this, KASAN may see an error in ioviterrevert():

BUG: KASAN: slab-out-of-bounds in ioviterrevert lib/ioviter.c:633 [inline] BUG: KASAN: slab-out-of-bounds in ioviterrevert+0x443/0x5a0 lib/ioviter.c:611 Read of size 4 at addr ffff88802912a0b8 by task kworker/u32:7/1147

CPU: 1 UID: 0 PID: 1147 Comm: kworker/u32:7 Not tainted 6.15.0-rc6-syzkaller-00052-g9f35e33144ae #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: eventsunbound netfswritecollectionworker Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xc3/0x670 mm/kasan/report.c:521 kasanreport+0xe0/0x110 mm/kasan/report.c:634 ioviterrevert lib/ioviter.c:633 [inline] ioviterrevert+0x443/0x5a0 lib/ioviter.c:611 netfsretrywritestream fs/netfs/writeretry.c:44 [inline] netfsretrywrites+0x166d/0x1a50 fs/netfs/writeretry.c:231 netfscollectwriteresults fs/netfs/writecollect.c:352 [inline] netfswritecollectionworker+0x23fd/0x3830 fs/netfs/writecollect.c:374 processonework+0x9cf/0x1b70 kernel/workqueue.c:3238 processscheduledworks kernel/workqueue.c:3319 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 retfromfork+0x45/0x80 arch/x86/kernel/process.c:153 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>

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

net: wwan: t7xx: Fix napi rx poll issue

When driver handles the napi rx polling requests, the netdev might have been released by the dellink logic triggered by the disconnect operation on user plane. However, in the logic of processing skb in polling, an invalid netdev is still being used, which causes a panic.

BUG: kernel NULL pointer dereference, address: 00000000000000f1 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:devgroreceive+0x3a/0x620 [...] Call Trace: <IRQ> ? diebody+0x68/0xb0 ? pagefaultoops+0x379/0x3e0 ? excpagefault+0x4f/0xa0 ? asmexcpagefault+0x22/0x30 ? pfxt7xxccmnirecvskb+0x10/0x10 [mtkt7xx (HASH:1400 7)] ? devgroreceive+0x3a/0x620 napigroreceive+0xad/0x170 t7xxccmnirecvskb+0x48/0x70 [mtkt7xx (HASH:1400 7)] t7xxdpmaifnapirxpoll+0x590/0x800 [mtkt7xx (HASH:1400 7)] netrxaction+0x103/0x470 irqexitrcu+0x13a/0x310 sysvecapictimerinterrupt+0x56/0x90 </IRQ>

bnxten: Set DMA unmap len correctly for XDPREDIRECT

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

smb: client: fix use-after-free in cryptmessage when using async crypto

The CVE-2024-50047 fix removed asynchronous crypto handling from cryptmessage(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:

cryptmessage() // Allocate the creq buffer containing the req creq = smb2getaeadreq(..., &req);

// Async encryption returns -EINPROGRESS immediately rc = enc ? cryptoaeadencrypt(req) : cryptoaeaddecrypt(req);

// Free creq while async operation is still in progress kvfreesensitive(creq, ...);

Hardware crypto modules often implement async AEAD operations for performance. When cryptoaeadencrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without cryptowaitreq(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.

This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.

The issue occurs because cryptoallocaead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTOALGASYNC in the mask, async implementations can be selected.

Fix by restoring the async crypto handling: - DECLARECRYPTOWAIT(wait) for completion tracking - aeadrequestsetcallback() for async completion notification - cryptowaitreq() to wait for operation completion

This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix.

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

smb: client: fix use-after-free in cifsoplockbreak

A race condition can occur in cifsoplockbreak() leading to a use-after-free of the cinode structure when unmounting:

cifsoplockbreak() cifsFileInfoput(cfile) cifsFileInfoputfinal() cifssbdeactive() [last ref, start releasing sb] killsb() killanonsuper() genericshutdownsuper() evictinodes() disposelist() evict() destroyinode() callrcu(&inode->ircu, icallback) spinlock(&cinode->openfilelock) <- OK [later] icallback() cifsfreeinode() kmemcachefree(cinode) spinunlock(&cinode->openfilelock) <- UAF cifsdoneoplockbreak(cinode) <- UAF

The issue occurs when umount has already released its reference to the superblock. When cifsFileInfoput() calls cifssbdeactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifsoplockbreak() continues to access the cinode after this point, resulting in use-after-free.

Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.

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

net: libwx: fix the using of Rx buffer DMA

The wxrxbuffer structure contained two DMA address fields: 'dma' and 'pagedma'. However, only 'pagedma' was actually initialized and used to program the Rx descriptor. But 'dma' was uninitialized and used in some paths.

This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized 'dma' was used. Althrough such error has not yet occurred, it is worth fixing in the code.

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

ksmbd: fix PreauhHashValue race condition

If client send multiple session setup requests to ksmbd, PreauhHashValue race condition could happen. There is no need to free sess->PreauhHashValue at session setup phase. It can be freed together with session at connection termination phase.

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

drbd: add missing krefget in handlewriteconflicts

With two-primaries enabled, DRBD tries to detect "concurrent" writes and handle write conflicts, so that even if you write to the same sector simultaneously on both nodes, they end up with the identical data once the writes are completed.

In handling "superseeded" writes, we forgot a krefget, resulting in a premature drbddestroydevice and use after free, and further to kernel crashes with symptoms.

Relevance: No one should use DRBD as a random data generator, and apparently all users of "two-primaries" handle concurrent writes correctly on layer up. That is cluster file systems use some distributed lock manager, and live migration in virtualization environments stops writes on one node before starting writes on the other node.

Which means that other than for "test cases", this code path is never taken in real life.

FYI, in DRBD 9, things are handled differently nowadays. We still detect "write conflicts", but no longer try to be smart about them. We decided to disconnect hard instead: upper layers must not submit concurrent writes. If they do, that's their fault.

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

tls: fix handling of zero-length records on the rxlist

Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record

If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rxlist. Next recvmsg() will pick it up from there.

Queuing the skb to rxlist after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length).

Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rxlist, and it's zero length.

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

cifs: Fix oops due to uninitialised variable

Fix smb3inittransformrq() to initialise buffer to NULL before calling netfsallocfolioqbuffer() as netfs assumes it can append to the buffer it is given. Setting it to NULL means it should start a fresh buffer, but the value is currently undefined.

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

libceph: fix invalid accesses to cephconnectionv1info

There is a place where generic code in messenger.c is reading and another place where it is writing to con->v1 union member without checking that the union member is active (i.e. msgr1 is in use).

On 64-bit systems, con->v1.authretry overlaps with con->v2.outiter, so such a read is almost guaranteed to return a bogus value instead of 0 when msgr2 is in use. This ends up being fairly benign because the side effect is just the invalidation of the authorizer and successive fetching of new tickets.

con->v1.connectseq overlaps with con->v2.connbufs and the fact that it's being written to can cause more serious consequences, but luckily it's not something that happens often.

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

smb: client: let smbddestroy() call disableworksync(&info->postsendcreditswork)

In smbddestroy() we may destroy the memory so we better wait until postsendcreditswork is no longer pending and will never be started again.

I actually just hit the case using rxe:

WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxeverbs.c:1032 rxepostrecv+0x1ee/0x480 [rdmarxe] ... [ 5305.686979] [ T138] smbdpostrecv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687149] [ T138] ? kasancheckwrite+0x14/0x30 [ 5305.687185] [ T138] ? pfxsmbdpostrecv+0x10/0x10 [cifs] [ 5305.687329] [ T138] ? pfxrawspinlockirqsave+0x10/0x10 [ 5305.687356] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687368] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687378] [ T138] ? rawspinunlockirqrestore+0x11/0x60 [ 5305.687389] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687399] [ T138] ? getreceivebuffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbdpostsendcredits+0x382/0x4b0 [cifs] [ 5305.687701] [ T138] ? pfxsmbdpostsendcredits+0x10/0x10 [cifs] [ 5305.687855] [ T138] ? pfxschedule+0x10/0x10 [ 5305.687865] [ T138] ? pfxrawspinlockirq+0x10/0x10 [ 5305.687875] [ T138] ? queuedelayedworkon+0x8e/0xa0 [ 5305.687889] [ T138] processonework+0x629/0xf80 [ 5305.687908] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687917] [ T138] ? kasancheckwrite+0x14/0x30 [ 5305.687933] [ T138] workerthread+0x87f/0x1570 ...

It means rxepostrecv was called after rdmadestroyqp(). This happened because putreceivebuffer() was triggered by ibdrainqp() and called: queuework(info->workqueue, &info->postsendcreditswork);

devlink: rate: Unset parent pointer in devlratenodesdestroy

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

nvmet-tcp: add bounds checks in nvmettcpbuildpduiovec

nvmettcpbuildpduiovec() could walk past cmd->req.sg when a PDU length or offset exceeds sgcnt and then use bogus sg->length/offset values, leading to copytoiter() GPF/KASAN. Guard sgidx, remaining entries, and sg->length/offset before building the bvec.

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

drm/display/dpmst: Add protection against 0 vcpi

When releasing a timeslot there is a slight chance we may end up with the wrong payload mask due to overflow if the delayeddestroywork ends up coming into play after a DP 2.1 monitor gets disconnected which causes vcpi to become 0 then we try to make the payload = ~BIT(vcpi - 1) which is a negative shift. VCPI id should never really be 0 hence skip changing the payload mask if VCPI is 0.

Otherwise it leads to <7> [515.287237] xe 0000:03:00.0: [drm:drmdpmstgetportmalloc [drmdisplayhelper]] port ffff888126ce9000 (3) <4> [515.287267] -----------[ cut here ]----------- <3> [515.287268] UBSAN: shift-out-of-bounds in ../drivers/gpu/drm/display/drmdpmsttopology.c:4575:36 <3> [515.287271] shift exponent -1 is negative <4> [515.287275] CPU: 7 UID: 0 PID: 3108 Comm: kworker/u64:33 Tainted: G S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT(voluntary) <4> [515.287279] Tainted: [S]=CPUOUTOFSPEC, [U]=USER <4> [515.287279] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 1645 03/15/2024 <4> [515.287281] Workqueue: drmdpmstwq drmdpdelayeddestroywork [drmdisplayhelper] <4> [515.287303] Call Trace: <4> [515.287304] <TASK> <4> [515.287306] dumpstacklvl+0xc1/0xf0 <4> [515.287313] dumpstack+0x10/0x20 <4> [515.287316] ubsanhandleshiftoutofbounds+0x133/0x2e0 <4> [515.287324] ? drmatomicgetprivateobjstate+0x186/0x1d0 <4> [515.287333] drmdpatomicreleasetimeslots.cold+0x17/0x3d [drmdisplayhelper] <4> [515.287355] mstconnectoratomiccheck+0x159/0x180 [xe] <4> [515.287546] drmatomichelpercheckmodeset+0x4d9/0xfa0 <4> [515.287550] ? wwmutexlock.constprop.0+0x6f/0x1a60 <4> [515.287562] intelatomiccheck+0x119/0x2b80 [xe] <4> [515.287740] ? findheldlock+0x31/0x90 <4> [515.287747] ? lockrelease+0xce/0x2a0 <4> [515.287754] drmatomiccheckonly+0x6a2/0xb40 <4> [515.287758] ? drmatomicaddaffectedconnectors+0x12b/0x140 <4> [515.287765] drmatomiccommit+0x6e/0xf0 <4> [515.287766] ? pfxdrmprintfninfo+0x10/0x10 <4> [515.287774] drmclientmodesetcommitatomic+0x25c/0x2b0 <4> [515.287794] drmclientmodesetcommitlocked+0x60/0x1b0 <4> [515.287795] ? mutexlocknested+0x1b/0x30 <4> [515.287801] drmclientmodesetcommit+0x26/0x50 <4> [515.287804] drmfbhelperrestorefbdevmodeunlocked+0xdc/0x110 <4> [515.287810] drmfbhelperhotplugevent+0x120/0x140 <4> [515.287814] drmfbdevclienthotplug+0x28/0xd0 <4> [515.287819] drmclienthotplug+0x6c/0xf0 <4> [515.287824] drmclientdevhotplug+0x9e/0xd0 <4> [515.287829] drmkmshelperhotplugevent+0x1a/0x30 <4> [515.287834] drmdpdelayeddestroywork+0x3df/0x410 [drmdisplayhelper] <4> [515.287861] processonework+0x22b/0x6f0 <4> [515.287874] workerthread+0x1e8/0x3d0 <4> [515.287879] ? pfxworkerthread+0x10/0x10 <4> [515.287882] kthread+0x11c/0x250 <4> [515.287886] ? pfxkthread+0x10/0x10 <4> [515.287890] retfromfork+0x2d7/0x310 <4> [515.287894] ? pfxkthread+0x10/0x10 <4> [515.287897] retfromforkasm+0x1a/0x30

dm cache policy smq: fix missing locks in invalidating cache blocks

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

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

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

serial: 8250dw: unregister 8250 port if clknotifierregister() fails

dw8250probe() registers the 8250 port via serial8250register8250port() and then, if the device has a clock, registers a clock notifier. If clknotifierregister() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250unregisterport() lives in dw8250remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved privatedata and serialin/serialout callbacks), so any access to that port slot before a rebind is a use-after-free hazard.

Unregister the port on the clknotifierregister() error path.

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

pNFS: Fix use-after-free in pnfsupdatelayout()

When hitting the NFSLAYOUTRETURN branch in pnfsupdatelayout(), the code calls pnfspreparetoretrylayoutget(lo). If it succeeds, pnfsputlayouthdr(lo) is called before tracepnfsupdatelayout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields.

Fix this by moving the tracepoint call before pnfsputlayouthdr(lo).

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

net: tls: prevent chain-after-chain in plain text SG

Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link:

This would create a chain where the wrap link points directly to another chain link. The scatterlist API sgnext iterator does not recursively resolve consecutive chain links.

meaning this is illegal input to crypto.

The wrapping link is unnecessary if end = 0. end is the entry after the last one used so end = 0 means there's nothing pushed after the wrap:

end start i v v v [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap]

Skip the wrapping in this case.

TLS 1.3 can use the "wrapping slot" for it's chaining if end = 0. This avoids the chain-after-chain.

Move the wrap chaining before marking END and chaining off content type, that feels like more logical ordering to me, but should not matter from functional perspective.