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

bnxten: Fix double DMA unmapping for XDPREDIRECT

Remove the dmaunmappageattrs() call in the driver's XDPREDIRECT code path. This should have been removed when we let the page pool handle the DMA mapping. This bug causes the warning:

WARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommudmaunmappage+0xd5/0x100 CPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024 RIP: 0010:iommudmaunmappage+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0 ? showregs+0x6d/0x80 ? warn+0x89/0x150 ? iommudmaunmappage+0xd5/0x100 ? reportbug+0x16a/0x190 ? handlebug+0x51/0xa0 ? excinvalidop+0x18/0x80 ? iommudmaunmappage+0xd5/0x100 ? iommudmaunmappage+0x35/0x100 dmaunmappageattrs+0x55/0x220 ? bpfprog4d7e87c0d30db711xdpdispatcher+0x64/0x9f bnxtrxxdp+0x237/0x520 [bnxten] bnxtrxpkt+0x640/0xdd0 [bnxten] bnxtpollwork+0x1a1/0x3d0 [bnxten] bnxtpoll+0xaa/0x1e0 [bnxten] napipoll+0x33/0x1e0 netrxaction+0x18a/0x2f0

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

clk: bcm: dvp: Assign ->num before accessing ->hws

Commit f316cdff8d67 ("clk: Annotate struct clkhwonecelldata with countedby") annotated the hws member of 'struct clkhwonecelldata' with countedby, which informs the bounds sanitizer about the number of elements in hws, so that it can warn when hws is accessed out of bounds. As noted in that change, the countedby member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in clkdvpprobe() due to ->num being assigned after ->hws has been accessed:

UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2 index 0 is out of range for type 'struct clkhw [] countedby(num)' (aka 'struct clkhw []')

Move the ->num initialization to before the first access of ->hws, which clears up the warning.

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

atl1c: Work around the DMA RX overflow issue

The Linux kernel CVE team has assigned CVE-2023-52834 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052109-CVE-2023-52834-4c46@gregkh/T

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

iommufd: Fix missing update of domainsitree after splitting ioptarea

In ioptareasplit(), if the original ioptarea has filled a domain and is linked to domainsitree, pagesnodes have to be properly reinserted. Otherwise the domainsitree becomes corrupted and we will UAF.

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

Bluetooth: hcievent: Fix handling of HCIEVIOCAPAREQUEST

If we received HCIEVIOCAPAREQUEST while HCIOPREADREMOTEEXTFEATURES is yet to be responded assume the remote does support SSP since otherwise this event shouldn't be generated.

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

Bluetooth: btusb: mediatek: Fix double free of skb in coredump

hcidevcdappend() would free the skb on error so the caller don't have to free it again otherwise it would cause the double free of skb.

Reported-by : Dan Carpenter <dan.carpenter@linaro.org>

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

swiotlb: fix out-of-bounds TLB allocations with CONFIGSWIOTLBDYNAMIC

Limit the free list length to the size of the IO TLB. Transient pool can be smaller than IOTLBSEGSIZE, but the free list is initialized with the assumption that the total number of slots is a multiple of IOTLBSEGSIZE. As a result, swiotlbareafindslots() may allocate slots past the end of a transient IO TLB buffer.

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

wifi: ath12k: fix htt mlo-offset event locking

The ath12k active pdevs are protected by RCU but the htt mlo-offset event handling code calling ath12kmacgetarbypdevid() was not marked as a read-side critical section.

Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues.

Compile tested only.

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

wifi: ath12k: fix dfs-radar and temperature event locking

The ath12k active pdevs are protected by RCU but the DFS-radar and temperature event handling code calling ath12kmacgetarbypdevid() was not marked as a read-side critical section.

Mark the code in question as RCU read-side critical sections to avoid any potential use-after-free issues.

Note that the temperature event handler looks like a place holder currently but would still trigger an RCU lockdep splat.

Compile tested only.

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

wifi: ath11k: fix dfs radar event locking

The ath11k active pdevs are protected by RCU but the DFS radar event handling code calling ath11kmacgetarbypdevid() was not marked as a read-side critical section.

Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues.

Compile tested only.

Bluetooth: btmtk: avoid UAF in btmtkprocesscoredump

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

ksmbd: fix slab out of bounds write in smbinheritdacl()

slab out-of-bounds write is caused by that offsets is bigger than pntsd allocation size. This patch add the check to validate 3 offsets using allocation size.

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

ksmbd: fix null pointer dereference in allocpreauthhash()

The Client send malformed smb2 negotiate request. ksmbd return error response. Subsequently, the client can send smb2 session setup even thought conn->preauthinfo is not allocated. This patch add KSMBDSESSNEEDSETUP status of connection to ignore session setup request if smb2 negotiate phase is not complete.

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

ksmbd: fix potencial OOB in getfileallinfo() for compound requests

When a compound request consists of QUERYDIRECTORY + QUERYINFO (FILEALLINFORMATION) and the first command consumes nearly the entire maxtranssize, getfileallinfo() would blindly call smbConvertToUTF16() with PATHMAX, causing out-of-bounds write beyond the response buffer. In getfileallinfo(), there was a missing validation check for the client-provided OutputBufferLength before copying the filename into FileName field of the smb2fileallinfo structure. If the filename length exceeds the available buffer space, it could lead to potential buffer overflows or memory corruption during smbConvertToUTF16 conversion. This calculating the actual free buffer size using smb2calcmaxoutbuflen() and returning -EINVAL if the buffer is insufficient and updating smbConvertToUTF16 to use the actual filename length (clamped by PATHMAX) to ensure a safe copy operation.

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

ksmbd: fix OOB write in QUERYINFO for compound requests

When a compound request such as READ + QUERYINFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor.

The root cause was that smb2getinfosec() checked buffer space using ppntsdsize from xattr, while buildsecdesc() often synthesized a significantly larger descriptor from POSIX ACLs.

This patch introduces smbaclsecdescscratchlen() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2calcmaxoutbuflen(), and uses exact-sized allocation + iov pinning.

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

ksmbd: replace hardcoded hdr2len with offsetof() in smb2calcmaxoutbuflen()

After this commit (e2b76ab8b5c9 "ksmbd: add support for read compound"), response buffer management was changed to use dynamic iov array. In the new design, smb2calcmaxoutbuflen() expects the second argument (hdr2len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value.

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

ksmbd: fix out-of-bounds write in smb2getea() EA alignment

smb2getea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buffreelen is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space.

When the EA value exactly fills the remaining buffer (buffreelen == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buffreelen boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERYINFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory.

Add a bounds check before the alignment memset to ensure buffreelen can accommodate the padding bytes.

This is the same bug pattern fixed by commit beef2634f81f ("ksmbd: fix potencial OOB in getfileallinfo() for compound requests") and commit fda9522ed6af ("ksmbd: fix OOB write in QUERYINFO for compound requests"), both of which added bounds checks before unconditional writes in QUERYINFO response handlers.

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

vmxnet3: Fix packet corruption in vmxnet3xdpxmitframe

Andrew and Nikolay reported connectivity issues with Cilium's service load-balancing in case of vmxnet3.

If a BPF program for native XDP adds an encapsulation header such as IPIP and transmits the packet out the same interface, then in case of vmxnet3 a corrupted packet is being sent and subsequently dropped on the path.

vmxnet3xdpxmitframe() which is called e.g. via vmxnet3runxdp() through vmxnet3xdpxmitback() calculates an incorrect DMA address:

page = virttopage(xdpf->data); tbi->dmaaddr = pagepoolgetdmaaddr(page) + VMXNET3XDPHEADROOM; dmasyncsinglefordevice(&adapter->pdev->dev, tbi->dmaaddr, bufsize, DMATODEVICE);

The above assumes a fixed offset (VMXNET3XDPHEADROOM), but the XDP BPF program could have moved xdp->data. While the passed bufsize is correct (xdpf->len), the dmaaddr needs to have a dynamic offset which can be calculated as xdpf->data - (void )xdpf, that is, xdp->data - xdp->datahardstart.

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

wifi: wilc1000: use vmmtable as array in wilc struct

Enabling KASAN and running some iperf tests raises some memory issues with vmmtable:

BUG: KASAN: slab-out-of-bounds in wilcwlanhandletxq+0x6ac/0xdb4 Write of size 4 at addr c3a61540 by task wlan0-tx/95

KASAN detects that we are writing data beyond range allocated to vmmtable. There is indeed a mismatch between the size passed to allocator in wilcwlaninit, and the range of possible indexes used later: allocation size is missing a multiplication by sizeof(u32)

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

f2fs: compress: fix to avoid use-after-free on dic

Call trace: memcpy+0x128/0x250 f2fsreadmultipages+0x940/0xf7c f2fsmpagereadpages+0x5a8/0x624 f2fsreadahead+0x5c/0x110 pagecacheraunbounded+0x1b8/0x590 dosyncmmapreadahead+0x1dc/0x2e4 filemapfault+0x254/0xa8c f2fsfilemapfault+0x2c/0x104 dofault+0x7c/0x238 dohandlemmfault+0x11bc/0x2d14 domemabort+0x3a8/0x1004 el0da+0x3c/0xa0 el0t64synchandler+0xc4/0xec el0t64sync+0x1b4/0x1b8

In f2fsreadmultipages(), once f2fsdecompresscluster() was called if we hit cached page in compressinode's cache, dic may be released, it needs break the loop rather than continuing it, in order to avoid accessing invalid dic pointer.

bpf: Fix undefined behavior in interpreter sdiv/smod for INTMIN

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

arm64: tlb: Fix TLBI RANGE operand

KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty pages are collected by VMM and the page table entries become write protected during live migration. Unfortunately, the operand passed to the TLBI RANGE instruction isn't correctly sorted out due to the commit 117940aa6e5f ("KVM: arm64: Define kvmtlbflushvmidrange()"). It leads to crash on the destination VM after live migration because TLBs aren't flushed completely and some of the dirty pages are missed.

For example, I have a VM where 8GB memory is assigned, starting from 0x40000000 (1GB). Note that the host has 4KB as the base page size. In the middile of migration, kvmtlbflushvmidrange() is executed to flush TLBs. It passes MAXTLBIRANGEPAGES as the argument to kvmtlbflushvmidrange() and flushs2tlbrangeop(). SCALE#3 and NUM#31, corresponding to MAXTLBIRANGEPAGES, isn't supported by TLBIRANGENUM(). In this specific case, -1 has been returned from TLBIRANGENUM() for SCALE#3/2/1/0 and rejected by the loop in the flushtlbrangeop() until the variable @scale underflows and becomes -9, 0xffff708000040000 is set as the operand. The operand is wrong since it's sorted out by TLBIVADDRRANGE() according to invalid @scale and @num.

Fix it by extending TLBIRANGENUM() to support the combination of SCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can be returned from the macro, meaning the TLBs for 0x200000 pages in the above example can be flushed in one shoot with SCALE#3 and NUM#31. The macro TLBIRANGEMASK is dropped since no one uses it any more. The comments are also adjusted accordingly.

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

kdb: Fix buffer overflow during tab-complete

Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer.

Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around.

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

xsk: validate MTU against usable frame size on bind

AFXDP bind currently accepts zero-copy pool configurations without verifying that the device MTU fits into the usable frame space provided by the UMEM chunk.

This becomes a problem since we started to respect tailroom which is subtracted from chunksize (among with headroom). 2k chunk size might not provide enough space for standard 1500 MTU, so let us catch such settings at bind time. Furthermore, validate whether underlying HW will be able to satisfy configured MTU wrt XSK's frame size multiplied by supported Rx buffer chain length (that is exposed via netdevice::xdpzcmaxsegs).

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

libceph: just wait for more data to be available on the socket

A short read may occur while reading the message footer from the socket. Later, when the socket is ready for another read, the messenger invokes all readpartial() handlers, including readpartialsparsemsgdata(). The expectation is that readpartialsparsemsgdata() would bail, allowing the messenger to invoke readpartial() for the footer and pick up where it left off.

However readpartialsparsemsgdata() violates that and ends up calling into the state machine in the OSD client. The sparse-read state machine assumes that it's a new op and interprets some piece of the footer as the sparse-read header and returns bogus extents/data length, etc.

To determine whether readpartialsparsemsgdata() should bail, let's reuse cursor->totalresid. Because once it reaches to zero that means all the extents and data have been successfully received in last read, else it could break out when partially reading any of the extents and data. And then osdsparseread() could continue where it left off.

[ idryomov: changelog ]

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

xsk: recycle buffer in case Rx queue was full

Add missing xskbufffree() call when xskrcvzc() failed to produce descriptor to XSK Rx queue.

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

tcp: correct handling of extreme memory squeeze

Testing with iperf3 using the "pasta" protocol splicer has revealed a problem in the way tcp handles window advertising in extreme memory squeeze situations.

Under memory pressure, a socket endpoint may temporarily advertise a zero-sized window, but this is not stored as part of the socket data. The reasoning behind this is that it is considered a temporary setting which shouldn't influence any further calculations.

However, if we happen to stall at an unfortunate value of the current window size, the algorithm selecting a new value will consistently fail to advertise a non-zero window once we have freed up enough memory. This means that this side's notion of the current window size is different from the one last advertised to the peer, causing the latter to not send any data to resolve the sitution.

The problem occurs on the iperf3 server side, and the socket in question is a completely regular socket with the default settings for the fedora40 kernel. We do not use SOPEEK or SORCVBUF on the socket.

The following excerpt of a logging session, with own comments added, shows more in detail what is happening:

// tcpv4rcv(->) // tcprcvestablished(->) [5201<->39222]: ==== Activating log @ net/ipv4/tcpinput.c/tcpdataqueue()/5257 ==== [5201<->39222]: tcpdataqueue(->) [5201<->39222]: DROPPING skb [265600160..265665640], reason: SKBDROPREASONPROTOMEM [rcvnxt 265600160, rcvwnd 262144, sntack 265469200, winnow 131184] [copiedseq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0] [5201<->39222]: tcpdataqueue(<-) [5201<->39222]: tcptransmitskb(->) [tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160] [5201<->39222]: tcpselectwindow(->) [5201<->39222]: (inetcsk(sk)->icskack.pending & ICSKACKNOMEM) ? --> TRUE [tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160] returning 0 [5201<->39222]: tcpselectwindow(<-) [5201<->39222]: ADVERTISING WIN 0, ACKSEQ: 265600160 [5201<->39222]: [tcptransmitskb(<-) [5201<->39222]: tcprcvestablished(<-) [5201<->39222]: tcpv4rcv(<-)

// Receive queue is at 85 buffers and we are out of memory. // We drop the incoming buffer, although it is in sequence, and decide // to send an advertisement with a window of zero. // We don't update tp->rcvwnd and tp->rcvwup accordingly, which means // we unconditionally shrink the window.

[5201<->39222]: tcprecvmsglocked(->) [5201<->39222]: tcpcleanuprbuf(->) tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160 [5201<->39222]: [newwin = 0, winnow = 131184, 2 winnow = 262368] [5201<->39222]: [newwin >= (2 winnow) ? --> timetoack = 0] [5201<->39222]: NOT calling tcpsendack() [tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160] [5201<->39222]: tcpcleanuprbuf(<-) [rcvnxt 265600160, rcvwnd 262144, sntack 265469200, winnow 131184] [copiedseq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0] returning 6104 bytes [5201<->39222]: tcprecvmsglocked(<-)

// After each read, the algorithm for calculating the new receive // window in tcpcleanuprbuf() finds it is too small to advertise // or to update tp->rcvwnd. // Meanwhile, the peer thinks the window is zero, and will not send // any more data to trigger an update from the interrupt mode side.

[5201<->39222]: tcprecvmsglocked(->) [5201<->39222]: tcpcleanuprbuf(->) tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160 [5201<->39222]: [newwin = 262144, winnow = 131184, 2 winn ---truncated---

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

net: ethernet: mtkethsoc: fix SER panic with 4GB+ RAM

If the mtkpollrx() function detects the MTKRESETTING flag, it will jump to releasedesc and refill the high word of the SDP on the 4GB RFB. Subsequently, mtkrxclean will process an incorrect SDP, leading to a panic.

Add patch from MediaTek's SDK to resolve this.

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

iommufd: Fix ioptaccesslistid overwrite bug

Syzkaller reported the following WARNON: WARNING: CPU: 1 PID: 4738 at drivers/iommu/iommufd/iopagetable.c:1360

Call Trace: iommufdaccesschangeioas+0x2fe/0x4e0 iommufdaccessdestroyobject+0x50/0xb0 iommufdobjectremove+0x2a3/0x490 iommufdobjectdestroyuser iommufdaccessdestroy+0x71/0xb0 iommufdteststaccessrelease+0x89/0xd0 fput+0x272/0xb50 fputsync+0x4b/0x60 dosysclose sesysclose x64sysclose+0x8b/0x110 dosyscallx64

The mismatch between the access pointer in the list and the passed-in pointer is resulting from an overwrite of access->ioptaccesslistid, in ioptaddaccess(). Called from iommufdaccesschangeioas() when xaalloc() succeeds but ioptcalculateiovaalignment() fails.

Add a newid in ioptaddaccess() and only update ioptaccesslistid when returning successfully.

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

irqchip/gic-v3-its: Restore quirk probing for ACPI-based systems

While refactoring the way the ITSs are probed, the handling of quirks applicable to ACPI-based platforms was lost. As a result, systems such as HIP07 lose their GICv4 functionnality, and some other may even fail to boot, unless they are configured to boot with DT.

Move the enabling of quirks into itsprobeone(), making it common to all firmware implementations.