In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in ksmbdsessionsderegister()
In multichannel mode, UAF issue can occur in sessionderegister when the second channel sets up a session through the connection of the first channel. session that is freed through the global session table can be accessed again through ->sessions of connection.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix session use-after-free in multichannel connection
There is a race condition between session setup and ksmbdsessionsderegister. The session can be freed before the connection is added to channel list of session. This patch check reference count of session before freeing it.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix overflow in dacloffset bounds check
The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smbcheckpermdacl() and smbinheritdacl().
This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer.
This patch converts dacloffset to unsigned int and uses checkaddoverflow() to validate access to the DACL.
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:
RDMA/mlx5: Fix mlx5pollone() curqp update flow
When curqp isn't NULL, in order to avoid fetching the QP from the radix tree again we check if the next cqe QP is identical to the one we already have.
The bug however is that we are checking if the QP is identical by checking the QP number inside the CQE against the QP number inside the mlx5ibqp, but that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5coreqp which is our FW QP number.
Otherwise we could use the wrong QP when handling a CQE which could cause the kernel trace below.
This issue is mainly noticeable over QPs 0 & 1, since for now they are the only QPs in our driver whereas the QP number inside mlx5ibqp doesn't match the QP number inside mlx5coreqp.
BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ibcqpollwork [ibcore] RIP: 0010:mlx5ibpollcq+0x4c7/0xd90 [mlx5ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: <TASK> ? die+0x20/0x60 ? pagefaultoops+0x150/0x3e0 ? excpagefault+0x74/0x130 ? asmexcpagefault+0x22/0x30 ? mlx5ibpollcq+0x4c7/0xd90 [mlx5ib] ibprocesscq+0x5a/0x150 [ibcore] ibcqpollwork+0x31/0x90 [ibcore] processonework+0x169/0x320 workerthread+0x288/0x3a0 ? workbusy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreadsonlinecpu+0x130/0x130 ? kthreadsonlinecpu+0x130/0x130 retfromfork+0x2d/0x50 ? kthreadsonlinecpu+0x130/0x130 retfromforkasm+0x11/0x20 </TASK>
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:
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:
wifi: ath12k: Fix invalid entry fetch in ath12kdpmonsrngprocess
Currently, ath12kdpmonsrngprocess uses ath12khalsrngsrcgetnextentry to fetch the next entry from the destination ring. This is incorrect because ath12khalsrngsrcgetnextentry is intended for source rings, not destination rings. This leads to invalid entry fetches, causing potential data corruption or crashes due to accessing incorrect memory locations. This happens because the source ring and destination ring have different handling mechanisms and using the wrong function results in incorrect pointer arithmetic and ring management.
To fix this issue, replace the call to ath12khalsrngsrcgetnextentry with ath12khalsrngdstgetnextentry in ath12kdpmonsrngprocess. This ensures that the correct function is used for fetching entries from the destination ring, preventing invalid memory accesses.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPLSILICONZ-1 Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPLV1.0V2.0SILICONZ-3
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:
KVM: arm64: Fix ID register initialization for non-protected pKVM guests
In protected mode, the hypervisor maintains a separate instance of the kvm structure for each VM. For non-protected VMs, this structure is initialized from the host's kvm state.
Currently, pkvminitfeaturesfromhost() copies the KVMARCHFLAGIDREGSINITIALIZED flag from the host without the underlying idregs data being initialized. This results in the hypervisor seeing the flag as set while the ID registers remain zeroed.
Consequently, kvmhasfeat() checks at EL2 fail (return 0) for non-protected VMs. This breaks logic that relies on feature detection, such as ctxthastcrx() for TCR2EL1 support. As a result, certain system registers (e.g., TCR2EL1, PIREL1, POREL1) are not saved/restored during the world switch, which could lead to state corruption.
Fix this by explicitly copying the ID registers from the host kvm to the hypervisor kvm for non-protected VMs during initialization, since we trust the host with its non-protected guests' features. Also ensure KVMARCHFLAGIDREGSINITIALIZED is cleared initially in pkvminitfeaturesfromhost so that vmcopyidregs can properly initialize them and set the flag once done.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free in l2capunregisteruser
After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hcichandel"), l2capconndel() uses conn->lock to protect access to conn->users. However, l2capregisteruser() and l2capunregisteruser() don't use conn->lock, creating a race condition where these functions can access conn->users and conn->hchan concurrently with l2capconndel().
This can lead to use-after-free and list corruption bugs, as reported by syzbot.
Fix this by changing l2capregisteruser() and l2capunregisteruser() to use conn->lock instead of hcidevlock(), ensuring consistent locking for the l2capconn structure.
In the Linux kernel, the following vulnerability has been resolved:
xfrm: iptfs: fix use-after-free on firstskb in inputprocesspayload
inputprocesspayload() stores firstskb into xtfs->ranewskb under droplock when starting partial reassembly, then unlocks and breaks out of the processing loop. The post-loop check reads xtfs->ranewskb without the lock to decide whether firstskb is still owned:
if (firstskb && firstiplen && !defer && firstskb != xtfs->ranewskb)
Between spinunlock and this read, a concurrent CPU running iptfsreassemcont() (or the droptimer hrtimer) can complete reassembly, NULL xtfs->ranewskb, and free the skb. The check then evaluates firstskb != NULL as true, and pskbtrim/ipsummed/consumeskb operate on the freed skb — a use-after-free in skbuffheadcache.
Replace the unlocked read with a local bool that records whether firstskb was handed to the reassembly state in the current call. The flag is set after the existing spinunlock, before the break, using the pointer equality that is stable at that point (firstskb == skb iff firstskb was stored in ranewskb).
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().
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:
ksmbd: validate zero numsubauth before subauth is accessed
Access psid->subauth[psid->numsubauth - 1] without checking if numsubauth is non-zero leads to an out-of-bounds read. This patch adds a validation step to ensure numsubauth != 0 before subauth is accessed.
In the Linux kernel, the following vulnerability has been resolved:
net: ppp: Add bound checking for skb data on pppsynctxmung
Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets.
When pppsynctxmung receives an incoming package with an empty payload: (remote) gef➤ p (struct pppoehdr ) (skb->head + skb->networkheader) $18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96 }
from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, datalen = 0x0, maclen = 0xe, hdrlen = 0x0,
it is not safe to access data[2].
[pabeni: fixed subj typo]
In the Linux kernel, the following vulnerability has been resolved:
iptunnel: adapt iptunnelxmitstats() to NETDEVPCPUSTATDSTATS
Blamed commits forgot that vxlan/geneve use udptunnel[6]xmitskb() which call iptunnelxmitstats().
iptunnelxmitstats() was assuming tunnels were only using NETDEVPCPUSTATTSTATS.
@syncp offset in pcpuswnetstats and pcpudstats is different.
32bit kernels would either have corruptions or freezes if the syncp sequence was overwritten.
This patch also moves pcpustattype closer to dev->{t,d}stats to avoid a potential cache line miss since iptunnelxmitstats() needs to read it.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add bounds check for create lease context
Add missing bounds check for create lease context.
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:
memstick: rtsxusbms: Fix slab-use-after-free in rtsxusbmsdrvremove
This fixes the following crash:
================================================================== BUG: KASAN: slab-use-after-free in rtsxusbmspollcard+0x159/0x200 [rtsxusbms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241
CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNEDMODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsxusbmspollcard [rtsxusbms] Call Trace: <TASK> dumpstacklvl+0x51/0x70 printaddressdescription.constprop.0+0x27/0x320 ? rtsxusbmspollcard+0x159/0x200 [rtsxusbms] printreport+0x3e/0x70 kasanreport+0xab/0xe0 ? rtsxusbmspollcard+0x159/0x200 [rtsxusbms] rtsxusbmspollcard+0x159/0x200 [rtsxusbms] ? pfxrtsxusbmspollcard+0x10/0x10 [rtsxusbms] ? pfxschedule+0x10/0x10 ? kickpool+0x3b/0x270 processonework+0x357/0x660 workerthread+0x390/0x4c0 ? pfxworkerthread+0x10/0x10 kthread+0x190/0x1d0 ? pfxkthread+0x10/0x10 retfromfork+0x2d/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>
Allocated by task 161446: kasansavestack+0x20/0x40 kasansavetrack+0x10/0x30 kasankmalloc+0x7b/0x90 kmallocnoprof+0x1a7/0x470 memstickallochost+0x1f/0xe0 [memstick] rtsxusbmsdrvprobe+0x47/0x320 [rtsxusbms] platformprobe+0x60/0xe0 calldriverprobe+0x35/0x120 reallyprobe+0x123/0x410 driverprobedevice+0xc7/0x1e0 driverprobedevice+0x49/0xf0 deviceattachdriver+0xc6/0x160 busforeachdrv+0xe4/0x160 deviceattach+0x13a/0x2b0 busprobedevice+0xbd/0xd0 deviceadd+0x4a5/0x760 platformdeviceadd+0x189/0x370 mfdadddevice+0x587/0x5e0 mfdadddevices+0xb1/0x130 rtsxusbprobe+0x28e/0x2e0 [rtsxusb] usbprobeinterface+0x15c/0x460 calldriverprobe+0x35/0x120 reallyprobe+0x123/0x410 driverprobedevice+0xc7/0x1e0 driverprobedevice+0x49/0xf0 deviceattachdriver+0xc6/0x160 busforeachdrv+0xe4/0x160 deviceattach+0x13a/0x2b0 rebindmarkedinterfaces.isra.0+0xcc/0x110 usbresetdevice+0x352/0x410 usbdevdoioctl+0xe5c/0x1860 usbdevioctl+0xa/0x20 x64sysioctl+0xc5/0xf0 dosyscall64+0x59/0x170 entrySYSCALL64afterhwframe+0x76/0x7e
Freed by task 161506: kasansavestack+0x20/0x40 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x36/0x60 kasanslabfree+0x34/0x50 kfree+0x1fd/0x3b0 devicerelease+0x56/0xf0 kobjectcleanup+0x73/0x1c0 rtsxusbmsdrvremove+0x13d/0x220 [rtsxusbms] platformremove+0x2f/0x50 devicereleasedriverinternal+0x24b/0x2e0 busremovedevice+0x124/0x1d0 devicedel+0x239/0x530 platformdevicedel.part.0+0x19/0xe0 platformdeviceunregister+0x1c/0x40 mfdremovedevicesfn+0x167/0x170 deviceforeachchildreverse+0xc9/0x130 mfdremovedevices+0x6e/0xa0 rtsxusbdisconnect+0x2e/0xd0 [rtsxusb] usbunbindinterface+0xf3/0x3f0 devicereleasedriverinternal+0x24b/0x2e0 procdisconnectclaim+0x13d/0x220 usbdevdoioctl+0xb5e/0x1860 usbdevioctl+0xa/0x20 x64sysioctl+0xc5/0xf0 dosyscall64+0x59/0x170 entrySYSCALL64afterhwframe+0x76/0x7e
Last potentially related work creation: kasansavestack+0x20/0x40 kasanrecordauxstack+0x85/0x90 insertwork+0x29/0x100 queuework+0x34a/0x540 calltimerfn+0x2a/0x160 expiretimers+0x5f/0x1f0 runtimerbase.part.0+0x1b6/0x1e0 runtimersoftirq+0x8b/0xe0 handlesoftirqs+0xf9/0x360 irqexitrcu+0x114/0x130 sysvecapictimerinterrupt+0x72/0x90 asmsysvecapictimerinterrupt+0x16/0x20
Second to last potentially related work creation: kasansavestack+0x20/0x40 kasanrecordauxstack+0x85/0x90 insertwork+0x29/0x100 queuework+0x34a/0x540 calltimerfn+0x2a/0x160 expiretimers+0x5f/0x1f0 runtimerbase.part.0+0x1b6/0x1e0 runtimersoftirq+0x8b/0xe0 handlesoftirqs+0xf9/0x ---truncated---
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:
usb: xhci: Apply the link chain quirk on NEC isoc endpoints
Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment:
[ 1.041954] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhcihcd: AMD-Vi: Event logged [IOPAGEFAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhcihcd: AMD-Vi: Event logged [IOPAGEFAULT domain=0x0005 address=0xffa09040 flags=0x0000]
It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.
[ 7.041671] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhcihcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 31 [ 7.042144] xhcihcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 31 [ 7.042266] xhcihcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.
[ 7.098130] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 13 [ 7.098132] xhcihcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 13 [ 7.098256] xhcihcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhcihcd: Overrun event on slot 1 ep 2
It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain.
Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board.
[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhcihcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVEROK cmdage=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 physseg 5 prio class 0
Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set.
The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times.
No ne ---truncated---
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.