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:
netfilter: nfnetlinkqueue: Initialize ctx to avoid memory allocation error
It is possible that ctx in nfqnlbuildpacketmessage() could be used before it is properly initialize, which is only initialized by nfqnlgetsksecctx().
This patch corrects this problem by initializing the lsmctx to a safe value when it is declared.
This is similar to the commit 35fcac7a7c25 ("audit: Initialize lsmctx to avoid memory allocation error").
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:
kthread: consolidate kthread exit paths to prevent use-after-free
Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rbnode with an 8-byte rhashhead in struct pid, shrinking it from 160 to 144 bytes.
struct kthread (without CONFIGBLKCGROUP) is also 144 bytes. With CONFIGSLABMERGEDEFAULT and SLABHWCACHEALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinitynode both sit at offset 0x78.
When a kthread exits via maketaskdead() it bypasses kthreadexit() and misses the affinitynode cleanup. freekthreadstruct() frees the memory while the node is still linked into the global kthreadaffinitylist. A subsequent listdel() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer.
Instead of patching freekthreadstruct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthreadexit() into a macro that calls doexit() and add kthreaddoexit() which is called from doexit() for any task with PFKTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - maketaskdead(), direct doexit(), or kthreadexit().
Replace tokthread() with a new tskiskthread() accessor in the public header. Export doexit() since module code using the kthreadexit() macro now needs it directly.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add bounds check for durable handle context
Add missing bounds check for durable handle context.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix rcount dec/increment mismatch
rcount is only increased when there is an oplock break wait, so rcount inc/decrement are not paired. This can cause rcount to become negative, which can lead to a problem where the ksmbd thread does not terminate.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Tear down vGIC on failed vCPU creation
If kvmarchvcpucreate() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU.
Add the missing cleanup to kvmarchvcpucreate(), ensuring that the vGIC vCPU structures are destroyed on error.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Fix uninitialized memcache pointer in usermemabort()
Commit fce886a60207 ("KVM: arm64: Plumb the pKVM MMU in KVM") made the initialization of the local memcache variable in usermemabort() conditional, leaving a codepath where it is used uninitialized via kvmpgtablestage2map().
This can fail on any path that requires a stage-2 allocation without transition via a permission fault or dirty logging.
Fix this by making sure that memcache is always valid.
In the Linux kernel, the following vulnerability has been resolved:
scsi: fnic: Fix crash in fnicwqcmplhandler when FDMI times out
When both the RHBA and RPA FDMI requests time out, fnic reuses a frame to send ABTS for each of them. On send completion, this causes an attempt to free the same frame twice that leads to a crash.
Fix crash by allocating separate frames for RHBA and RPA, and modify ABTS logic accordingly.
Tested by checking MDS for FDMI information.
Tested by using instrumented driver to:
- Drop PLOGI response - Drop RHBA response - Drop RPA response - Drop RHBA and RPA response - Drop PLOGI response + ABTS response - Drop RHBA response + ABTS response - Drop RPA response + ABTS response - Drop RHBA and RPA response + ABTS response for both of them
In the Linux kernel, the following vulnerability has been resolved:
nvmet: pci-epf: Do not complete commands twice if nvmetreqinit() fails
Have nvmetreqinit() and req->execute() complete failed commands.
Description of the problem: nvmetreqinit() calls nvmetreqcomplete() internally upon failure, e.g., unsupported opcode, which calls the "queueresponse" callback, this results in nvmetpciepfqueueresponse() being called, which will call nvmetpciepfcompleteiod() if datalen is 0 or if dmadir is different from DMATODEVICE. This results in a double completion as nvmetpciepfexeciodwork() also calls nvmetpciepfcompleteiod() when nvmetreqinit() fails.
Steps to reproduce: On the host send a command with an unsupported opcode with nvme-cli, For example the admin command "security receive" $ sudo nvme security-recv /dev/nvme0n1 -n1 -x4096
This triggers a double completion as nvmetreqinit() fails and nvmetpciepfqueueresponse() is called, here iod->dmadir is still in the default state of "DMANONE" as set by default in nvmetpciepfallociod(), so nvmetpciepfcompleteiod() is called. Because nvmetreqinit() failed nvmetpciepfcompleteiod() is also called in nvmetpciepfexeciodwork() leading to a double completion. This not only sends two completions to the host but also corrupts the state of the PCI NVMe target leading to kernel oops.
This patch lets nvmetreqinit() and req->execute() complete all failed commands, and removes the double completion case in nvmetpciepfexeciodwork() therefore fixing the edge cases where double completions occurred.
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:
wifi: ath12k: Fix invalid data access in ath12kdprxhundecapnwifi
In certain cases, hardware might provide packets with a length greater than the maximum native Wi-Fi header length. This can lead to accessing and modifying fields in the header within the ath12kdprxhundecapnwifi function for DPRXDECAPTYPENATIVEWIFI decap type and potentially resulting in invalid data access and memory corruption.
Add a sanity check before processing the SKB to prevent invalid data access in the undecap native Wi-Fi function for the DPRXDECAPTYPENATIVEWIFI decap type.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPLSILICONZ-1
In the Linux kernel, the following vulnerability has been resolved:
virt: sev-guest: Explicitly leak pages in unknown state
When setmemory{encrypted,decrypted}() fail, the user cannot know at which point the function failed, meaning that the pages are left in an unknown state from the point of view of the caller.
Since the pages may be left in an unencrypted state, they are not suitable for general use, and cannot be returned safely to the buddy allocator. Avoid the issue by never freeing the pages, and then do the proper accounting by calling snpleakpages().
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfttunnel: fix geneveopt type confusion addition
When handling multiple NFTATUNNELKEYOPTSGENEVE attributes, the parsing logic should place every geneveopt structure one by one compactly. Hence, when deciding the next geneveopt position, the pointer addition should be in units of char .
However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write.
[ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nfttunnelobjinit+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] <TASK> [ 6.992586] dumpstacklvl+0x44/0x5c [ 6.992801] printreport+0x184/0x4be [ 6.993790] kasanreport+0xc5/0x100 [ 6.994252] kasancheckrange+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nfttunnelobjinit+0x977/0xa70 [ 6.995677] nftobjinit+0x10c/0x1b0 [ 6.995891] nftablesnewobj+0x585/0x950 [ 6.996922] nfnetlinkrcvbatch+0xdf9/0x1020 [ 6.998997] nfnetlinkrcv+0x1df/0x220 [ 6.999537] netlinkunicast+0x395/0x530 [ 7.000771] netlinksendmsg+0x3d0/0x6d0 [ 7.001462] socksendmsg+0x99/0xa0 [ 7.001707] syssendmsg+0x409/0x450 [ 7.002391] syssendmsg+0xfd/0x170 [ 7.003145] syssendmsg+0xea/0x170 [ 7.004359] dosyscall64+0x5e/0x90 [ 7.005817] entrySYSCALL64afterhwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIGRAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8
Fix this bug with correct pointer addition and conversion in parse and dump code.
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix off-by-one error in dosplit
Syzkaller detected a use-after-free issue in ext4insertdentry that was caused by out-of-bounds access due to incorrect splitting in dosplit.
BUG: KASAN: use-after-free in ext4insertdentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847
CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 kasancheckrange+0x282/0x290 mm/kasan/generic.c:189 asanmemcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4insertdentry+0x36a/0x6d0 fs/ext4/namei.c:2109 adddirenttobuf+0x3d9/0x750 fs/ext4/namei.c:2154 makeindexeddir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4addentry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4addnondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfssymlink+0x137/0x2e0 fs/namei.c:4615 dosymlinkat+0x222/0x3a0 fs/namei.c:4641 dosyssymlink fs/namei.c:4662 [inline] sesyssymlink fs/namei.c:4660 [inline] x64syssymlink+0x7a/0x90 fs/namei.c:4660 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>
The following loop is located right above 'if' statement.
for (i = count-1; i >= 0; i--) { / is more than half of this entry in 2nd half of the block? / if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; }
'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
In the Linux kernel, the following vulnerability has been resolved:
xfrm: iptfs: reset runtime state when cloning SAs
iptfsclonestate() clones the IPTFS mode data with kmemdup(). This copies runtime objects which must not be shared with the original SA, including the embedded skbuffhead, hrtimers, spinlock, and in-flight reassembly/reorder state.
If xfrmstatemigrate() fails after clonestate() but before the later initstate() call has reinitialized those fields, the cloned state can be destroyed by xfrmstategctask() with list and timer state copied from the original SA. With queued packets this lets the clone splice and free skbs owned by the original IPTFS queue, leading to use-after-free and double-free reports in iptfsdestroystate() and skb release paths.
Reinitialize the clone's runtime state before publishing it through x->modedata. Because clonestate() now publishes a destroyable modedata object before initstate(), take the mode callback module reference there. Avoid taking it again from iptfsinitstate() for the same object.
fs/ntfs3: Prevent integer overflow in hdrfirstde()
In the Linux kernel, the following vulnerability has been resolved:
ASoC: simple-card-utils: Don't use free(devicenode) at graphutilparsedai()
commit 419d1918105e ("ASoC: simple-card-utils: use free(devicenode) for device node") uses free(devicenode) for dlc->ofnode, but we need to keep it while driver is in use.
Don't use free(devicenode) in graphutilparsedai().
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add a check to handle OOB in sfr region
sfr->bufsize is in shared memory and can be modified by malicious user. OOB write is possible when the size is made higher than actual sfr data buffer. Cap the size to allocated size for such cases.
In the Linux kernel, the following vulnerability has been resolved:
HID: intel-thc-hid: intel-quicki2c: Fix ACPI dsd ICRS/ISUB length
The QuickI2C ACPI DSD methods return ICRS and ISUB data with a trailing byte, making the actual length is one more byte than the structs defined.
It caused stack-out-of-bounds and kernel crash:
kernel: BUG: KASAN: stack-out-of-bounds in quicki2cacpigetdsdproperty.constprop.0+0x111/0x1b0 [intelquicki2c] kernel: Write of size 12 at addr ffff888106d1f900 by task kworker/u33:2/75 kernel: kernel: CPU: 3 UID: 0 PID: 75 Comm: kworker/u33:2 Not tainted 6.16.0+ #3 PREEMPT(voluntary) kernel: Workqueue: async asyncrunentryfn kernel: Call Trace: kernel: <TASK> kernel: dumpstacklvl+0x76/0xa0 kernel: printreport+0xd1/0x660 kernel: ? pfxrawspinlockirqsave+0x10/0x10 kernel: ? kasanslabfree+0x5d/0x80 kernel: ? kasanaddrtoslab+0xd/0xb0 kernel: kasanreport+0xe1/0x120 kernel: ? quicki2cacpigetdsdproperty.constprop.0+0x111/0x1b0 [intelquicki2c] kernel: ? quicki2cacpigetdsdproperty.constprop.0+0x111/0x1b0 [intelquicki2c] kernel: kasancheckrange+0x11c/0x200 kernel: asanmemcpy+0x3b/0x80 kernel: quicki2cacpigetdsdproperty.constprop.0+0x111/0x1b0 [intelquicki2c] kernel: ? pfxquicki2cacpigetdsdproperty.constprop.0+0x10/0x10 [intelquicki2c] kernel: quicki2cgetacpiresources+0x237/0x730 [intelquicki2c] [...] kernel: </TASK> kernel: kernel: The buggy address belongs to stack of task kworker/u33:2/75 kernel: and is located at offset 48 in frame: kernel: quicki2cgetacpiresources+0x0/0x730 [intelquicki2c] kernel: kernel: This frame has 3 objects: kernel: [32, 36) 'hiddescaddr' kernel: [48, 59) 'i2cparam' kernel: [80, 224) 'i2cconfig'
ACPI DSD methods return:
\SB.PC00.THC0.ICRS Buffer 000000003fdc947b 001 Len 0C = 0A 00 80 1A 06 00 00 00 00 00 00 00 \SB.PC00.THC0.ISUB Buffer 00000000f2fcbdc4 001 Len 91 = 00 00 00 00 00 00 00 00 00 00 00 00
Adding reserved padding to quicki2csubipacpiparameter/config.
In the Linux kernel, the following vulnerability has been resolved:
mailbox: mchp-ipc-sbi: fix out-of-bounds access in mchpipcgetclusteraggrirq()
The clustercfg array is dynamically allocated to hold per-CPU configuration structures, with its size based on the number of online CPUs. Previously, this array was indexed using hartid, which may be non-contiguous or exceed the bounds of the array, leading to out-of-bounds access. Switch to using cpuid as the index, as it is guaranteed to be within the valid range provided by foreachonlinecpu().
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix NULL pointer in canacceptnewsubflow
When testing valkey benchmark tool with MPTCP, the kernel panics in 'mptcpcanacceptnewsubflow' because subflowreq->msk is NULL.
Call trace:
mptcpcanacceptnewsubflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P) subflowsynrecvsock (./net/mptcp/subflow.c:854) tcpcheckreq (./net/ipv4/tcpminisocks.c:863) tcpv4rcv (./net/ipv4/tcpipv4.c:2268) ipprotocoldeliverrcu (./net/ipv4/ipinput.c:207) iplocaldeliverfinish (./net/ipv4/ipinput.c:234) iplocaldeliver (./net/ipv4/ipinput.c:254) iprcvfinish (./net/ipv4/ipinput.c:449) ...
According to the debug log, the same req received two SYN-ACK in a very short time, very likely because the client retransmits the syn ack due to multiple reasons.
Even if the packets are transmitted with a relevant time interval, they can be processed by the server on different CPUs concurrently). The 'subflowreq->msk' ownership is transferred to the subflow the first, and there will be a risk of a null pointer dereference here.
This patch fixes this issue by moving the 'subflowreq->msk' under the ownreq == true conditional.
Note that the !msk check in subflowhmacvalid() can be dropped, because the same check already exists under the ownreq mpj branch where the code has been moved to.
In the Linux kernel, the following vulnerability has been resolved:
net: libwx: handle pagepooldevallocpages error
pagepooldevallocpages could return NULL. There was a WARNON(!page) but it would still proceed to use the NULL pointer and then crash.
This is similar to commit 001ba0902046 ("net: fec: handle pagepooldevallocpages error").
This is found by our static analysis tool KNighter.
In the Linux kernel, the following vulnerability has been resolved:
ice: fix Rx page leak on multi-buffer frames
The iceputrxmbuf() function handles calling iceputrxbuf() for each buffer in the current frame. This function was introduced as part of handling multi-buffer XDP support in the ice driver.
It works by iterating over the buffers from firstdesc up to 1 plus the total number of fragments in the frame, cached from before the XDP program was executed.
If the hardware posts a descriptor with a size of 0, the logic used in iceputrxmbuf() breaks. Such descriptors get skipped and don't get added as fragments in iceaddxdpfrag. Since the buffer isn't counted as a fragment, we do not iterate over it in iceputrxmbuf(), and thus we don't call iceputrxbuf().
Because we don't call iceputrxbuf(), we don't attempt to re-use the page or free it. This leaves a stale page in the ring, as we don't increment nexttoalloc.
The icereuserxpage() assumes that the nexttoalloc has been incremented properly, and that it always points to a buffer with a NULL page. Since this function doesn't check, it will happily recycle a page over the top of the nexttoalloc buffer, losing track of the old page.
Note that this leak only occurs for multi-buffer frames. The iceputrxmbuf() function always handles at least one buffer, so a single-buffer frame will always get handled correctly. It is not clear precisely why the hardware hands us descriptors with a size of 0 sometimes, but it happens somewhat regularly with "jumbo frames" used by 9K MTU.
To fix iceputrxmbuf(), we need to make sure to call iceputrxbuf() on all buffers between firstdesc and nexttoclean. Borrow the logic of a similar function in i40e used for this same purpose. Use the same logic also in icegetpgcnts().
Instead of iterating over just the number of fragments, use a loop which iterates until the current index reaches to the nexttoclean element just past the current frame. Unlike i40e, the iceputrxmbuf() function does call iceputrxbuf() on the last buffer of the frame indicating the end of packet.
For non-linear (multi-buffer) frames, we need to take care when adjusting the pagecntbias. An XDP program might release fragments from the tail of the frame, in which case that fragment page is already released. Only update the pagecntbias for the first descriptor and fragments still remaining post-XDP program. Take care to only access the shared info for fragmented buffers, as this avoids a significant cache miss.
The xdpxmit value only needs to be updated if an XDP program is run, and only once per packet. Drop the xdpxmit pointer argument from iceputrxmbuf(). Instead, set xdpxmit in the icecleanrxirq() function directly. This avoids needing to pass the argument and avoids an extra bit-wise OR for each buffer in the frame.
Move the increment of the ntc local variable to ensure its updated before all calls to icegetpgcnts() or iceputrxmbuf(), as the loop logic requires the index of the element just after the current frame.
Now that we use an index pointer in the ring to identify the packet, we no longer need to track or cache the number of fragments in the rxring.
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Don't skip on Stopped - Length Invalid
Up until commit d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are returned when isoc ring is stopped") in v6.11, the driver didn't skip missed isochronous TDs when handling Stoppend and Stopped - Length Invalid events. Instead, it erroneously cleared the skip flag, which would cause the ring to get stuck, as future events won't match the missed TD which is never removed from the queue until it's cancelled.
This buggy logic seems to have been in place substantially unchanged since the 3.x series over 10 years ago, which probably speaks first and foremost about relative rarity of this case in normal usage, but by the spec I see no reason why it shouldn't be possible.
After d56b0b2ab142, TDs are immediately skipped when handling those Stopped events. This poses a potential problem in case of Stopped - Length Invalid, which occurs either on completed TDs (likely already given back) or Link and No-Op TRBs. Such event won't be recognized as matching any TD (unless it's the rare Link TRB inside a TD) and will result in skipping all pending TDs, giving them back possibly before they are done, risking isoc data loss and maybe UAF by HW.
As a compromise, don't skip and don't clear the skip flag on this kind of event. Then the next event will skip missed TDs. A downside of not handling Stopped - Length Invalid on a Link inside a TD is that if the TD is cancelled, its actual length will not be updated to account for TRBs (silently) completed before the TD was stopped.
I had no luck producing this sequence of completion events so there is no compelling demonstration of any resulting disaster. It may be a very rare, obscure condition. The sole motivation for this patch is that if such unlikely event does occur, I'd rather risk reporting a cancelled partially done isoc frame as empty than gamble with UAF.
This will be fixed more properly by looking at Stopped event's TRB pointer when making skipping decisions, but such rework is unlikely to be backported to v6.12, which will stay around for a few years.
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix use-after-free in printgraphfunctionflags during tracer switching
Kairui reported a UAF issue in printgraphfunctionflags() during ftrace stress testing [1]. This issue can be reproduced if puting a 'mdelay(10)' after 'mutexunlock(&tracetypeslock)' in sstart(), and executing the following script:
$ echo functiongraph > currenttracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > currenttracer
The root cause lies in the two calls to printgraphfunctionflags within printtraceline during each sshow():
One through 'iter->trace->printline()'; Another through 'event->funcs->trace()', which is hidden in printtracefmt() before printtraceline returns.
Tracer switching only updates the former, while the latter continues to use the printline function of the old tracer, which in the script above is printgraphfunctionflags.
Moreover, when switching from the 'functiongraph' tracer to the 'timerlat' tracer, sstart only calls graphtraceclose of the 'functiongraph' tracer to free 'iter->private', but does not set it to NULL. This provides an opportunity for 'event->funcs->trace()' to use an invalid 'iter->private'.
To fix this issue, set 'iter->private' to NULL immediately after freeing it in graphtraceclose(), ensuring that an invalid pointer is not passed to other tracers. Additionally, clean up the unnecessary 'iter->private = NULL' during each 'cat trace' when using wakeup and irqsoff tracers.
[1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/
In the Linux kernel, the following vulnerability has been resolved:
exfat: fix random stack corruption after getblock
When getblock is called with a bufferhead allocated on the stack, such as dompagereadpage, stack corruption due to bufferhead UAF may occur in the following race condition situation.
<CPU 0> <CPU 1> mpagereadfolio <<bh on stack>> dompagereadpage exfatgetblock bhread bhread getbh(bh) submitbh waitonbuffer ... endbufferreadsync endbufferreadnotouch unlockbuffer <<keep going>> ... ... ... ... <<bh is not valid out of mpagereadfolio>> . . anotherfunction <<variable A on stack>> putbh(bh) atomicdec(bh->bcount) stack corruption here
This patch returns -EAGAIN if a folio does not have buffers when bhread needs to be called. By doing this, the caller can fallback to functions like blockreadfullfolio(), create a bufferhead in the folio, and then call getblock again.
Let's do not call bhread() with on-stack bufferhead.
In the Linux kernel, the following vulnerability has been resolved:
x86/microcode/AMD: Fix applymicrocodeamd()'s return value
When verifysha256digest() fails, applymicrocodeamd() should propagate the failure by returning false (and not -1 which is promoted to true).
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Increase ARCHDMAMINALIGN up to 16
ARCHDMAMINALIGN is 1 by default, but some LoongArch-specific devices (such as APBDMA) require 16 bytes alignment. When the data buffer length is too small, the hardware may make an error writing cacheline. Thus, it is dangerous to allocate a small memory buffer for DMA. It's always safe to define ARCHDMAMINALIGN as L1CACHEBYTES but unnecessary (kmalloc() need small memory objects). Therefore, just increase it to 16.
In the Linux kernel, the following vulnerability has been resolved:
mm/gup: reject FOLLSPLITPMD with hugetlb VMAs
Patch series "mm: fixes for device-exclusive entries (hmm)", v2.
Discussing the PageTail() call in makedeviceexclusiverange() with Willy, I recently discovered [1] that device-exclusive handling does not properly work with THP, making the hmm-tests selftests fail if THPs are enabled on the system.
Looking into more details, I found that hugetlb is not properly fenced, and I realized that something that was bugging me for longer -- how device-exclusive entries interact with mapcounts -- completely breaks migration/swapout/split/hwpoison handling of these folios while they have device-exclusive PTEs.
The program below can be used to allocate 1 GiB worth of pages and making them device-exclusive on a kernel with CONFIGTESTHMM.
Once they are device-exclusive, these folios cannot get swapped out (proc$pid/smapsrollup will always indicate 1 GiB RSS no matter how much one forces memory reclaim), and when having a memory block onlined to ZONEMOVABLE, trying to offline it will loop forever and complain about failed migration of a page that should be movable.
echo offline > /sys/devices/system/memory/memory136/state echo onlinemovable > /sys/devices/system/memory/memory136/state ./hmm-swap & ... wait until everything is device-exclusive echo offline > /sys/devices/system/memory/memory136/state [ 285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x7f20671f7 pfn:0x442b6a [ 285.196618][T14882] memcg:ffff888179298000 [ 285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate| dirty|active|owner2|swapbacked|node=1|zone=3|lastcpupid=0x7ff) [ 285.201734][T14882] raw: ... [ 285.204464][T14882] raw: ... [ 285.207196][T14882] page dumped because: migration failure [ 285.209072][T14882] pageowner tracks the page as allocated [ 285.210915][T14882] page last allocated via order 0, migratetype Movable, gfpmask 0x140dca(GFPHIGHUSERMOVABLE|GFPCOMP|GFPZERO), id 14926, tgid 14926 (hmm-swap), ts 254506295376, freets 227402023774 [ 285.216765][T14882] postallochook+0x197/0x1b0 [ 285.218874][T14882] getpagefromfreelist+0x76e/0x3280 [ 285.220864][T14882] allocfrozenpagesnoprof+0x38e/0x2740 [ 285.223302][T14882] allocpagesmpol+0x1fc/0x540 [ 285.225130][T14882] folioallocmpolnoprof+0x36/0x340 [ 285.227222][T14882] vmaallocfolionoprof+0xee/0x1a0 [ 285.229074][T14882] handlemmfault+0x2b38/0x56a0 [ 285.230822][T14882] handlemmfault+0x368/0x9f0 ...
This series fixes all issues I found so far. There is no easy way to fix without a bigger rework/cleanup. I have a bunch of cleanups on top (some previous sent, some the result of the discussion in v1) that I will send out separately once this landed and I get to it.
I wish we could just use some special present PROTNONE PTEs instead of these (non-present, non-none) fake-swap entries; but that just results in the same problem we keep having (lack of spare PTE bits), and staring at other similar fake-swap entries, that ship has sailed.
With this series, makedeviceexclusive() doesn't actually belong into mm/rmap.c anymore, but I'll leave moving that for another day.
I only tested this series with the hmm-tests selftests due to lack of HW, so I'd appreciate some testing, especially if the interaction between two GPUs wanting a device-exclusive entry works as expected.
<program> #include <stdio.h> #include <fcntl.h> #include <stdint.h> #include <unistd.h> #include <stdlib.h> #include <string.h> #include <sys/mman.h> #include <sys/ioctl.h> #include <linux/types.h> #include <linux/ioctl.h>
#define HMMDMIRROREXCLUSIVE IOWR('H', 0x05, struct hmmdmirrorcmd)
struct hmmdmirrorcmd { u64 addr; u64 ptr; u64 npages; u64 cpages; u64 faults; };
const sizet size = 1 1024 1024 1024ul; const sizet chunksize = 2 1024 1024ul;
int m ---truncated---