Azure RTOS USBX Remote Code Execution Vulnerability

Azure RTOS USBX is a USB host, device, and on-the-go (OTG) embedded stack, that is fully integrated with Azure RTOS ThreadX. An attacker can cause remote code execution due to expired pointer dereference vulnerabilities in Azure RTOS USBX. The affected components include components in host class, related to CDC ACM in RTOS v6.2.1 and below. The fixes have been included in USBX release 6.3.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Azure RTOS USBX Remote Code Execution Vulnerability

Azure RTOS USBX is a USB host, device, and on-the-go (OTG) embedded stack, that is fully integrated with Azure RTOS ThreadX. An attacker can cause remote code execution due to expired pointer dereference and type confusion vulnerabilities in Azure RTOS USBX. The affected components include functions/processes in host stack and host class, related to device linked classes, ASIX, Prolific, SWAR, audio, CDC ECM in RTOS v6.2.1 and below. The fixes have been included in USBX release 6.3.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.

In Bandisoft Bandizip through 7.37, there is a Mark-of-the-Web Bypass Vulnerability. This vulnerability allows attackers to bypass the Mark-of-the-Web protection mechanism on affected installations of Bandizip. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of archived files. When extracting files from a crafted archive that bears the Mark-of-the-Web, Bandizip does not propagate the Mark-of-the-Web to the extracted files. An attacker can leverage this vulnerability to execute arbitrary code in the context of the current user. NOTE: this is disputed because Mark-of-the-Web propagation can increase risk via security-warning habituation, and because the intended control sphere for file-origin metadata (e.g., HostUrl in Zone.Identifier) may be narrower than that for reading the file's content.

In PeaZip through 10.4.0, there is a Mark-of-the-Web Bypass Vulnerability. This vulnerability allows attackers to bypass the Mark-of-the-Web protection mechanism on affected installations of PeaZip. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of archived files. When extracting files from a crafted archive that bears the Mark-of-the-Web, PeaZip does not propagate the Mark-of-the-Web to the extracted files. An attacker can leverage this vulnerability to execute arbitrary code in the context of the current user. NOTE: this is disputed because Mark-of-the-Web propagation can increase risk via security-warning habituation, and because the intended control sphere for file-origin metadata (e.g., HostUrl in Zone.Identifier) may be narrower than that for reading the file's content.

hostapd: RADIUS Packet Processing Flaw in hostapd

hostapd fails to process crafted RADIUS packets properly. When hostapd authenticates wi-fi devices with RADIUS authentication, an attacker in the position between the hostapd and the RADIUS server may inject crafted RADIUS packets and force RADIUS authentications to fail.

BIG-IP SSL vulnerability

When an SSL profile with alert timeout is configured with a non-default value on a virtual server, undisclosed traffic along with conditions beyond the attacker's control can cause the Traffic Management Microkernel (TMM) to terminate.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

BIG-IP IPsec vulnerability

When IPsec is configured on a virtual server, undisclosed traffic can cause the Traffic Management Microkernel (TMM) to terminate. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Ankitects Anki before 25.02.5 allows a crafted shared deck on Windows to execute arbitrary commands when playing audio because of URL scheme mishandling.

Cursor CLI: Arbitrary Code Execution Possible through Permissive CLI Config

Cursor is a code editor built for programming with AI. In versions 1.7 and below, automatic loading of project-specific CLI configuration from the current working directory (<project>/.cursor/cli.json) could override certain global configurations in Cursor CLI. This allowed users running the CLI inside a malicious repository to be vulnerable to Remote Code Execution through a combination of permissive configuration (allowing shell commands) and prompt injection delivered via project-specific Rules (<project>/.cursor/rules/rule.mdc) or other mechanisms. The fix for this issue is currently available as a patch 2025.09.17-25b418f. As of October 3, 2025 there is no release version.

Microsoft Office Graphics Remote Code Execution Vulnerability

Microsoft Office Graphics Remote Code Execution Vulnerability

VT Studio versions 8.53 and prior contain an access of uninitialized pointer vulnerability. If the product uses a specially crafted file, arbitrary code may be executed on the affected product.

libzvbi conv.c vbi_strndup_iconv_ucs2 uninitialized pointer

A vulnerability was found in libzvbi up to 0.2.43. It has been classified as problematic. Affected is the function vbi_strndup_iconv_ucs2 of the file src/conv.c. The manipulation of the argument src_length leads to uninitialized pointer. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 0.2.44 is able to address this issue. The patch is identified as 8def647eea27f7fd7ad33ff79c2d6d3e39948dce. It is recommended to upgrade the affected component. The code maintainer was informed beforehand about the issues. She reacted very fast and highly professional.

USB: gadget: dummy-hcd: Fix "task hung" problem

In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix "task hung" problem The syzbot fuzzer has been encountering "task hung" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new "timer_pending" flag and setting or clearing it at the appropriate times.

exfat: fix the new buffer was not zeroed before writing

In the Linux kernel, the following vulnerability has been resolved: exfat: fix the new buffer was not zeroed before writing Before writing, if a buffer_head marked as new, its data must be zeroed, otherwise uninitialized data in the page cache will be written. So this commit uses folio_zero_new_buffers() to zero the new buffers before ->write_end().

w1: fix WARNING after calling w1_process()

In the Linux kernel, the following vulnerability has been resolved: w1: fix WARNING after calling w1_process() I got the following WARNING message while removing driver(ds2482): ------------[ cut here ]------------ do not call blocking ops when !TASK_RUNNING; state=1 set at [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire] WARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0 CPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G N 6.1.0-rc3+ #307 RIP: 0010:__might_sleep+0x98/0xa0 Call Trace: exit_signals+0x6c/0x550 do_exit+0x2b4/0x17e0 kthread_exit+0x52/0x60 kthread+0x16d/0x1e0 ret_from_fork+0x1f/0x30 The state of task is set to TASK_INTERRUPTIBLE in loop in w1_process(), set it to TASK_RUNNING when it breaks out of the loop to avoid the warning.

Elastic Agent Inclusion of Functionality from Untrusted Control Sphere

Inclusion of functionality from an untrusted control sphere in Elastic Agent subprocess, osqueryd, allows local attackers to execute arbitrary code via parameter injection. An attacker requires local access and the ability to modify osqueryd configurations.

erofs: reliably distinguish block based and fscache mode

In the Linux kernel, the following vulnerability has been resolved: erofs: reliably distinguish block based and fscache mode When erofs_kill_sb() is called in block dev based mode, s_bdev may not have been initialised yet, and if CONFIG_EROFS_FS_ONDEMAND is enabled, it will be mistaken for fscache mode, and then attempt to free an anon_dev that has never been allocated, triggering the following warning: ============================================ ida_free called for id=0 which is not allocated. WARNING: CPU: 14 PID: 926 at lib/idr.c:525 ida_free+0x134/0x140 Modules linked in: CPU: 14 PID: 926 Comm: mount Not tainted 6.9.0-rc3-dirty #630 RIP: 0010:ida_free+0x134/0x140 Call Trace: <TASK> erofs_kill_sb+0x81/0x90 deactivate_locked_super+0x35/0x80 get_tree_bdev+0x136/0x1e0 vfs_get_tree+0x2c/0xf0 do_new_mount+0x190/0x2f0 [...] ============================================ Now when erofs_kill_sb() is called, erofs_sb_info must have been initialised, so use sbi->fsid to distinguish between the two modes.

drm/msm: Fix mmap to include VM_IO and VM_DONTDUMP

In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix mmap to include VM_IO and VM_DONTDUMP In commit 510410bfc034 ("drm/msm: Implement mmap as GEM object function") we switched to a new/cleaner method of doing things. That's good, but we missed a little bit. Before that commit, we used to _first_ run through the drm_gem_mmap_obj() case where `obj->funcs->mmap()` was NULL. That meant that we ran: vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); ...and _then_ we modified those mappings with our own. Now that `obj->funcs->mmap()` is no longer NULL we don't run the default code. It looks like the fact that the vm_flags got VM_IO / VM_DONTDUMP was important because we're now getting crashes on Chromebooks that use ARC++ while logging out. Specifically a crash that looks like this (this is on a 5.10 kernel w/ relevant backports but also seen on a 5.15 kernel): Unable to handle kernel paging request at virtual address ffffffc008000000 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000008293d000 [ffffffc008000000] pgd=00000001002b3003, p4d=00000001002b3003, pud=00000001002b3003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP [...] CPU: 7 PID: 15734 Comm: crash_dump64 Tainted: G W 5.10.67 #1 [...] Hardware name: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform (DT) pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--) pc : __arch_copy_to_user+0xc0/0x30c lr : copyout+0xac/0x14c [...] Call trace: __arch_copy_to_user+0xc0/0x30c copy_page_to_iter+0x1a0/0x294 process_vm_rw_core+0x240/0x408 process_vm_rw+0x110/0x16c __arm64_sys_process_vm_readv+0x30/0x3c el0_svc_common+0xf8/0x250 do_el0_svc+0x30/0x80 el0_svc+0x10/0x1c el0_sync_handler+0x78/0x108 el0_sync+0x184/0x1c0 Code: f8408423 f80008c3 910020c6 36100082 (b8404423) Let's add the two flags back in. While we're at it, the fact that we aren't running the default means that we _don't_ need to clear out VM_PFNMAP, so remove that and save an instruction. NOTE: it was confirmed that VM_IO was the important flag to fix the problem I was seeing, but adding back VM_DONTDUMP seems like a sane thing to do so I'm doing that too.

DotNetNuke.Core allows loading of unused themes on anonymous clients through query parameters

DNN (formerly DotNetNuke) is an open-source web content management platform (CMS) in the Microsoft ecosystem. Prior to version 10.1.0, arbitrary themes can be loaded through query parameters. If an installed theme had a vulnerability, even if it was not used on any page, this could be loaded on unsuspecting clients without knowledge of the site owner. This issue has been patched in version 10.1.0.

net: txgbe: initialize num_q_vectors for MSI/INTx interrupts

In the Linux kernel, the following vulnerability has been resolved: net: txgbe: initialize num_q_vectors for MSI/INTx interrupts When using MSI/INTx interrupts, wx->num_q_vectors is uninitialized. Thus there will be kernel panic in wx_alloc_q_vectors() to allocate queue vectors.