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:
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:
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:
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.
[ceph] parselongname(): strrchr() expects NUL-terminated string
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in ksmbdtreeconnectput under concurrency
Under high concurrency, A tree-connection object (tcon) is freed on a disconnect path while another path still holds a reference and later executes put()/write on it.
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:
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:
wifi: mac80211: don't return unset power in ieee80211gettxpower()
We can get a UBSAN warning if ieee80211gettxpower() returns the INTMIN value mac80211 internally uses for "unset power level".
UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dumpstack+0x74/0x92 ubsanepilogue+0x9/0x50 handleoverflow+0x8d/0xd0 ubsanhandlemuloverflow+0xe/0x10 nl80211sendiface+0x688/0x6b0 [cfg80211] [...] cfg80211registerwdev+0x78/0xb0 [cfg80211] cfg80211netdevnotifiercall+0x200/0x620 [cfg80211] [...] ieee80211ifadd+0x60e/0x8f0 [mac80211] ieee80211registerhw+0xda5/0x1170 [mac80211]
In this case, simply return an error instead, to indicate that no data is available.
In the Linux kernel, the following vulnerability has been resolved:
netconsole: avoid OOB reads, msg is not nul-terminated
msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 ("netconsole: convert to NBCON console infrastructure") the message would be placed in printksharedpbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see:
printk: console [netconext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netconext0/594
CPU: 65 UID: 0 PID: 594 Comm: pr/netconext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasanreport+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsolewrite+0x3fe/0xa10 nbconemitnextrecord+0x46e/0x860 nbconkthreadfunc+0x623/0x750
Allocated by task 1: nbconalloc+0x1ea/0x450 registerconsole+0x26b/0xe10 initnetconsole+0xbb0/0xda0
The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)
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.
In the Linux kernel, the following vulnerability has been resolved:
hsr: Prevent use after free in prpcreatetaggedframe()
The prpfillrct() function can fail. In that situation, it frees the skb and returns NULL. Meanwhile on the success path, it returns the original skb. So it's straight forward to fix bug by using the returned value.
Bluetooth: btmtk: avoid UAF in btmtkprocesscoredump
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:
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:
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:
wifi: ath12k: fix possible out-of-bound write in ath12kwmiexthalregcaps()
regcap.phyid is extracted from WMI event and could be an unexpected value in case some errors happen. As a result out-of-bound write may occur to soc->halregcap. Fix it by validating regcap.phyid before using it.
This is found during code review.
Compile tested only.
In the Linux kernel, the following vulnerability has been resolved:
fs/jfs: Add check for negative dbl2nbperpage
l2nbperpage is log2(number of blks per page), and the minimum legal value should be 0, not negative.
In the case of l2nbperpage being negative, an error will occur when subsequently used as shift exponent.
Syzbot reported this bug:
UBSAN: shift-out-of-bounds in fs/jfs/jfsdmap.c:799:12 shift exponent -16777216 is negative
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:
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:
shmem: fix recovery on rename failures
mapletree insertions can fail if we are seriously short on memory; simpleoffsetrename() does not recover well if it runs into that. The same goes for simpleoffsetrenameexchange().
Moreover, shmemwhiteout() expects that if it succeeds, the caller will progress to dmove(), i.e. that shmemrename2() won't fail past the successful call of shmemwhiteout().
Not hard to fix, fortunately - mtreestore() can't fail if the index we are trying to store into is already present in the tree as a singleton.
For simpleoffsetrenameexchange() that's enough - we just need to be careful about the order of operations.
For simpleoffsetrename() solution is to preinsert the target into the tree for newdir; the rest can be done without any potentially failing operations.
That preinsertion has to be done in shmemrename2() rather than in simpleoffsetrename() itself - otherwise we'd need to deal with the possibility of failure after successful shmemwhiteout().