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

tls: fix use-after-free on failed backlog decryption

When the decrypt request goes to the backlog and cryptoaeaddecrypt returns -EBUSY, tlsdodecryption will wait until all async decryptions have completed. If one of them fails, tlsdodecryption will return -EBADMSG and tlsdecryptsg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tlsdecryptdone.

The only true async case is when cryptoaeaddecrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tlsswrecvmsg that the data is available for immediate copy, but we need to notify tlsdecryptsg (via the new ->asyncdone flag) that the memory has already been released.

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

smb: client: fix potential UAF in smb2isvalidoplockbreak()

Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.

ceph: blocklist the kclient when receiving corrupted snap trace

hvnetvsc: Don't free decrypted memory

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

net: ena: Add validation for completion descriptors consistency

Validate that first flag is set only for the first descriptor in multi-buffer packets. In case of an invalid descriptor, a reset will occur. A new reset reason for RX data corruption has been added.

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

net/mlx5e: SHAMPO, Fix incorrect page release

Under the following conditions: 1) No skb created yet 2) headersize == 0 (no SHAMPO header) 3) headerindex + 1 % MLX5ESHAMPOWQHEADERPERPAGE == 0 (this is the last page fragment of a SHAMPO header page)

a new skb is formed with a page that is NOT a SHAMPO header page (it is a regular data page). Further down in the same function (mlx5ehandlerxcqempwrqshampo()), a SHAMPO header page from headerindex is released. This is wrong and it leads to SHAMPO header pages being released more than once.

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

net/smc: check v2extoffset/eidcnt/ismgidcnt when receiving proposal msg

When receiving proposal msg in server, the fields v2extoffset/ eidcnt/ismgidcnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2extoffset, once exceed the max value, there has the chance to access wrong address, and crash may happen.

This patch checks the fields v2extoffset/eidcnt/ismgidcnt before using them.

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

virtio-net: fix overflow inside virtnetrqalloc

When the frag just got a page, then may lead to regression on VM. Specially if the sysctl net.core.highorderallocdisable value is 1, then the frag always get a page when do refill.

Which could see reliable crashes or scp failure (scp a file 100M in size to VM).

The issue is that the virtnetrqdma takes up 16 bytes at the beginning of a new frag. When the frag size is larger than PAGESIZE, everything is fine. However, if the frag is only one page and the total size of the buffer and virtnetrqdma is larger than one page, an overflow may occur.

The commit f9dac92ba908 ("virtioring: enable premapped mode whatever usedmaapi") introduced this problem. And we reverted some commits to fix this in last linux version. Now we try to enable it and fix this bug directly.

Here, when the frag size is not enough, we reduce the buffer len to fix this problem.

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

nvme-tcp: fix potential memory corruption in nvmetcprecvpdu()

nvmetcprecvpdu() doesn't check the validity of the header length. When header digests are enabled, a target might send a packet with an invalid header length (e.g. 255), causing nvmetcpverifyhdgst() to access memory outside the allocated area and cause memory corruptions by overwriting it with the calculated digest.

Fix this by rejecting packets with an unexpected header length.

9p/net: fix improper handling of bogus negative read/write replies

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

nvme-tcp: sanitize request list handling

Validate the request in nvmetcphandler2t() to ensure it's not part of any list, otherwise a malicious R2T PDU might inject a loop in request list processing.

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:

nfsd: handle getclientlocked() failure in nfsd4setclientidconfirm()

Lei Lu recently reported that nfsd4setclientidconfirm() did not check the return value from getclientlocked(). a SETCLIENTIDCONFIRM could race with a confirmed client expiring and fail to get a reference. That could later lead to a UAF.

Fix this by getting a reference early in the case where there is an extant confirmed client. If that fails then treat it as if there were no confirmed client found at all.

In the case where the unconfirmed client is expiring, just fail and return the result from getclientlocked().

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

net, hsr: reject HSR frame if skb can't hold tag

Receiving HSR frame with insufficient space to hold HSR tag in the skb can result in a crash (kernel BUG):

[ 45.390915] skbuff: skbunderpanic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridgeslave1 [ 45.392559] ------------[ cut here ]------------ [ 45.392912] kernel BUG at net/core/skbuff.c:211! [ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUGPAGEALLOC KASAN NOPTI [ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef) [ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 45.395273] RIP: 0010:skbpanic+0x15b/0x1d0

<snip registers, remove unreliable trace>

[ 45.402911] Call Trace: [ 45.403105] <IRQ> [ 45.404470] skbpush+0xcd/0xf0 [ 45.404726] brdevqueuepushxmit+0x7c/0x6c0 [ 45.406513] brforwardfinish+0x128/0x260 [ 45.408483] brforward+0x42d/0x590 [ 45.409464] maybedeliver+0x2eb/0x420 [ 45.409763] brflood+0x174/0x4a0 [ 45.410030] brhandleframefinish+0xc7c/0x1bc0 [ 45.411618] brhandleframe+0xac3/0x1230 [ 45.413674] netifreceiveskbcore.constprop.0+0x808/0x3df0 [ 45.422966] netifreceiveskbonecore+0xb4/0x1f0 [ 45.424478] netifreceiveskb+0x22/0x170 [ 45.424806] processbacklog+0x242/0x6d0 [ 45.425116] napipoll+0xbb/0x630 [ 45.425394] netrxaction+0x4d1/0xcc0 [ 45.427613] handlesoftirqs+0x1a4/0x580 [ 45.427926] dosoftirq+0x74/0x90 [ 45.428196] </IRQ>

This issue was found by syzkaller.

The panic happens in brdevqueuepushxmit() once it receives a corrupted skb with ETH header already pushed in linear data. When it attempts the skbpush() call, there's not enough headroom and skbpush() panics.

The corrupted skb is put on the queue by HSR layer, which makes a sequence of unintended transformations when it receives a specific corrupted HSR frame (with incomplete TAG).

Fix it by dropping and consuming frames that are not long enough to contain both ethernet and hsr headers.

Alternative fix would be to check for enough headroom before skbpush() in brdevqueuepushxmit().

In the reproducer, this is injected via AFPACKET, but I don't easily see why it couldn't be sent over the wire from adjacent network.

Further Details:

In the reproducer, the following network interface chain is set up:

┌────────────────┐ ┌────────────────┐ │ veth0tohsr ├───┤ hsrslave0 ┼───┐ └────────────────┘ └────────────────┘ │ │ ┌──────┐ ├─┤ hsr0 ├───┐ │ └──────┘ │ ┌────────────────┐ ┌────────────────┐ │ │┌────────┐ │ veth1tohsr ┼───┤ hsrslave1 ├───┘ └┤ │ └────────────────┘ └────────────────┘ ┌┼ bridge │ ││ │ │└────────┘ │ ┌───────┐ │ │ ... ├──────┘ └───────┘

To trigger the events leading up to crash, reproducer sends a corrupted HSR fr ---truncated---

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

ppp: fix race conditions in pppfillforwardpath

pppfillforwardpath() has two race conditions:

1. The ppp->channels list can change between listempty() and listfirstentry(), as ppplock() is not held. If the only channel is deleted in pppdisconnectchannel(), listfirstentry() may access an empty head or a freed entry, and trigger a panic.

2. pch->chan can be NULL. When pppunregisterchannel() is called, pch->chan is set to NULL before pch is removed from ppp->channels.

Fix these by using a lockless RCU approach: - Use listfirstornullrcu() to safely test and access the first list entry. - Convert list modifications on ppp->channels to their RCU variants and add synchronizenet() after removal. - Check for a NULL pch->chan before dereferencing it.

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

ipv6: sr: Fix MAC comparison to be constant-time

To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.

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

net/smc: fix UAF on smcsk after smclistenout()

BPF CI testing report a UAF issue:

[ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0 [ 16.447134] #PF: supervisor read access in kernel mod e [ 16.447516] #PF: errorcode(0x0000) - not-present pag e [ 16.447878] PGD 0 P4D 0 [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2 [ 16.449124] Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODUL E [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4 [ 16.450201] Workqueue: smchswq smclistenwor k [ 16.450531] RIP: 0010:smclistenwork+0xc02/0x159 0 [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6 [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0 [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0 [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5 [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0 [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0 [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0 [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3 [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0 [ 16.456459] PKRU: 5555555 4 [ 16.456654] Call Trace : [ 16.456832] <TASK > [ 16.456989] ? die+0x23/0x7 0 [ 16.457215] ? pagefaultoops+0x180/0x4c 0 [ 16.457508] ? lockacquire+0x3e6/0x249 0 [ 16.457801] ? excpagefault+0x68/0x20 0 [ 16.458080] ? asmexcpagefault+0x26/0x3 0 [ 16.458389] ? smclistenwork+0xc02/0x159 0 [ 16.458689] ? smclistenwork+0xc02/0x159 0 [ 16.458987] ? lockisheldtype+0x8f/0x10 0 [ 16.459284] processonework+0x1ea/0x6d 0 [ 16.459570] workerthread+0x1c3/0x38 0 [ 16.459839] ? pfxworkerthread+0x10/0x1 0 [ 16.460144] kthread+0xe0/0x11 0 [ 16.460372] ? pfxkthread+0x10/0x1 0 [ 16.460640] retfromfork+0x31/0x5 0 [ 16.460896] ? pfxkthread+0x10/0x1 0 [ 16.461166] retfromforkasm+0x1a/0x3 0 [ 16.461453] </TASK > [ 16.461616] Modules linked in: bpftestmod(OE) [last unloaded: bpftestmod(OE) ] [ 16.462134] CR2: 000000000000003 0 [ 16.462380] ---[ end trace 0000000000000000 ]--- [ 16.462710] RIP: 0010:smclistenwork+0xc02/0x1590

The direct cause of this issue is that after smclistenoutconnected(), newclcsock->sk may be NULL since it will releases the smcsk. Therefore, if the application closes the socket immediately after accept, newclcsock->sk can be NULL. A possible execution order could be as follows:

smclistenwork | userspace ----------------------------------------------------------------- locksock(sk) | smclistenoutconnected() | | \- smclistenout | | | \- releasesock | | |- sk->skdataready() | | fd = accept(); | close(fd); | \- socket->sk = NULL; / newclcsock->sk is NULL now / SMCSTATSERVSUCCINC(socknet(newclcsock->sk))

Since smclistenoutconnected() will not fail, simply swapping the order of the code can easily fix this issue.

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

scsi: target: iscsi: Fix a race condition between loginwork and the login thread

In case a malicious initiator sends some random data immediately after a login PDU; the iscsitargetskdataready() callback will schedule the loginwork and, at the same time, the negotiation may end without clearing the LOGINFLAGSINITIALPDU flag (because no additional PDU exchanges are required to complete the login).

The login has been completed but the loginwork function will find the LOGINFLAGSINITIALPDU flag set and will never stop from rescheduling itself; at this point, if the initiator drops the connection, the iscsitconn structure will be freed, loginwork will dereference a released socket structure and the kernel crashes.

BUG: kernel NULL pointer dereference, address: 0000000000000230 PF: supervisor write access in kernel mode PF: errorcode(0x0002) - not-present page Workqueue: events iscsitargetdologinrx [iscsitargetmod] RIP: 0010:rawreadlockbh+0x15/0x30 Call trace: iscsitargetdologinrx+0x75/0x3f0 [iscsitargetmod] processonework+0x1e8/0x3c0

Fix this bug by forcing loginwork to stop after the login has been completed and the socket callbacks have been restored.

Add a comment to clearify the return values of iscsitargetdologin()

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

scsi: lpfc: Fix buffer free/clear order in deferred receive path

Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF.

Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same.

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

libceph: prevent potential out-of-bounds reads in handleauthdone()

Perform an explicit bounds check on payloadlen to avoid a possible out-of-bounds access in the callout.

[ idryomov: changelog ]

bpf: Scrub packet on bpfredirectpeer

dma-direct: Leak pages on dmasetdecrypted() failure

Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encrypted

ax25: fix use-after-free bugs caused by ax25dsdeltimer

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

wifi: iwlwifi: read txq->readptr under lock

If we read txq->readptr without lock, we can read the same value twice, then obtain the lock, and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in the WARNONCE() a little later. Fix that by reading txq->readptr under lock.

Bluetooth: hciconn: Use disabledelayedworksync

Bluetooth: hcievent: Ignore multiple conn complete events

Bluetooth: L2CAP: Fix slab-use-after-free Read in l2capsendcmd