Vulnerabilities

Reflected cross-site scripting (XSS) vulnerability in ClinCapture EDC 3.0 and 2.2.3, allowing an unauthenticated remote attacker to execute JavaScript code in the context of the victim's browser.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()<br /> <br /> Syzbot identified an issue [1] in pcl818_ai_cancel(), which stems from<br /> the fact that in case of early device detach via pcl818_detach(),<br /> subdevice dev-&gt;read_subdev may not have initialized its pointer to<br /> &amp;struct comedi_async as intended. Thus, any such dereferencing of<br /> &amp;s-&gt;async-&gt;cmd will lead to general protection fault and kernel crash.<br /> <br /> Mitigate this problem by removing a call to pcl818_ai_cancel() from<br /> pcl818_detach() altogether. This way, if the subdevice setups its<br /> support for async commands, everything async-related will be<br /> handled via subdevice&amp;#39;s own -&gt;cancel() function in<br /> comedi_device_detach_locked() even before pcl818_detach(). If no<br /> support for asynchronous commands is provided, there is no need<br /> to cancel anything either.<br /> <br /> [1] Syzbot crash:<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]<br /> CPU: 1 UID: 0 PID: 6050 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025<br /> RIP: 0010:pcl818_ai_cancel+0x69/0x3f0 drivers/comedi/drivers/pcl818.c:762<br /> ...<br /> Call Trace:<br /> <br /> pcl818_detach+0x66/0xd0 drivers/comedi/drivers/pcl818.c:1115<br /> comedi_device_detach_locked+0x178/0x750 drivers/comedi/drivers.c:207<br /> do_devconfig_ioctl drivers/comedi/comedi_fops.c:848 [inline]<br /> comedi_unlocked_ioctl+0xcde/0x1020 drivers/comedi/comedi_fops.c:2178<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> locking/spinlock/debug: Fix data-race in do_raw_write_lock<br /> <br /> KCSAN reports:<br /> <br /> BUG: KCSAN: data-race in do_raw_write_lock / do_raw_write_lock<br /> <br /> write (marked) to 0xffff800009cf504c of 4 bytes by task 1102 on cpu 1:<br /> do_raw_write_lock+0x120/0x204<br /> _raw_write_lock_irq<br /> do_exit<br /> call_usermodehelper_exec_async<br /> ret_from_fork<br /> <br /> read to 0xffff800009cf504c of 4 bytes by task 1103 on cpu 0:<br /> do_raw_write_lock+0x88/0x204<br /> _raw_write_lock_irq<br /> do_exit<br /> call_usermodehelper_exec_async<br /> ret_from_fork<br /> <br /> value changed: 0xffffffff -&gt; 0x00000001<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 PID: 1103 Comm: kworker/u4:1 6.1.111<br /> <br /> Commit 1a365e822372 ("locking/spinlock/debug: Fix various data races") has<br /> adressed most of these races, but seems to be not consistent/not complete.<br /> <br /> &gt;From do_raw_write_lock() only debug_write_lock_after() part has been<br /> converted to WRITE_ONCE(), but not debug_write_lock_before() part.<br /> Do it now.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corrupted<br /> <br /> There&amp;#39;s issue when file system corrupted:<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/jbd2/transaction.c:1289!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN PTI<br /> CPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next<br /> RIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0<br /> RSP: 0018:ffff888117aafa30 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534<br /> RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010<br /> RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028<br /> R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000<br /> R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> __ext4_journal_get_create_access+0x42/0x170<br /> ext4_getblk+0x319/0x6f0<br /> ext4_bread+0x11/0x100<br /> ext4_append+0x1e6/0x4a0<br /> ext4_init_new_dir+0x145/0x1d0<br /> ext4_mkdir+0x326/0x920<br /> vfs_mkdir+0x45c/0x740<br /> do_mkdirat+0x234/0x2f0<br /> __x64_sys_mkdir+0xd6/0x120<br /> do_syscall_64+0x5f/0xfa0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The above issue occurs with us in errors=continue mode when accompanied by<br /> storage failures. There have been many inconsistencies in the file system<br /> data.<br /> In the case of file system data inconsistency, for example, if the block<br /> bitmap of a referenced block is not set, it can lead to the situation where<br /> a block being committed is allocated and used again. As a result, the<br /> following condition will not be satisfied then trigger BUG_ON. Of course,<br /> it is entirely possible to construct a problematic image that can trigger<br /> this BUG_ON through specific operations. In fact, I have constructed such<br /> an image and easily reproduced this issue.<br /> Therefore, J_ASSERT() holds true only under ideal conditions, but it may<br /> not necessarily be satisfied in exceptional scenarios. Using J_ASSERT()<br /> directly in abnormal situations would cause the system to crash, which is<br /> clearly not what we want. So here we directly trigger a JBD abort instead<br /> of immediately invoking BUG_ON.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Fix possible deadlock in the deferred_irq_workfn()<br /> <br /> For PREEMPT_RT=y kernels, the deferred_irq_workfn() is executed in<br /> the per-cpu irq_work/* task context and not disable-irq, if the rq<br /> returned by container_of() is current CPU&amp;#39;s rq, the following scenarios<br /> may occur:<br /> <br /> lock(&amp;rq-&gt;__lock);<br /> <br /> lock(&amp;rq-&gt;__lock);<br /> <br /> This commit use IRQ_WORK_INIT_HARD() to replace init_irq_work() to<br /> initialize rq-&gt;scx.deferred_irq_work, make the deferred_irq_workfn()<br /> is always invoked in hard-irq context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd/pmc: Add support for Van Gogh SoC<br /> <br /> The ROG Xbox Ally (non-X) SoC features a similar architecture to the<br /> Steam Deck. While the Steam Deck supports S3 (s2idle causes a crash),<br /> this support was dropped by the Xbox Ally which only S0ix suspend.<br /> <br /> Since the handler is missing here, this causes the device to not suspend<br /> and the AMD GPU driver to crash while trying to resume afterwards due to<br /> a power hang.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/guc: Fix stack_depot usage<br /> <br /> Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is<br /> enabled to fix the following call stack:<br /> <br /> [] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [] Workqueue: drm_sched_run_job_work [gpu_sched]<br /> [] RIP: 0010:stack_depot_save_flags+0x172/0x870<br /> [] Call Trace:<br /> [] <br /> [] fast_req_track+0x58/0xb0 [xe]<br /> <br /> (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: renesas_usbhs: Fix synchronous external abort on unbind<br /> <br /> A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is<br /> executed after the configuration sequence described above:<br /> <br /> modprobe usb_f_ecm<br /> modprobe libcomposite<br /> modprobe configfs<br /> cd /sys/kernel/config/usb_gadget<br /> mkdir -p g1<br /> cd g1<br /> echo "0x1d6b" &gt; idVendor<br /> echo "0x0104" &gt; idProduct<br /> mkdir -p strings/0x409<br /> echo "0123456789" &gt; strings/0x409/serialnumber<br /> echo "Renesas." &gt; strings/0x409/manufacturer<br /> echo "Ethernet Gadget" &gt; strings/0x409/product<br /> mkdir -p functions/ecm.usb0<br /> mkdir -p configs/c.1<br /> mkdir -p configs/c.1/strings/0x409<br /> echo "ECM" &gt; configs/c.1/strings/0x409/configuration<br /> <br /> if [ ! -L configs/c.1/ecm.usb0 ]; then<br /> ln -s functions/ecm.usb0 configs/c.1<br /> fi<br /> <br /> echo 11e20000.usb &gt; UDC<br /> echo 11e20000.usb &gt; /sys/bus/platform/drivers/renesas_usbhs/unbind<br /> <br /> The displayed trace is as follows:<br /> <br /> Internal error: synchronous external abort: 0000000096000010 [#1] SMP<br /> CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT<br /> Tainted: [M]=MACHINE_CHECK<br /> Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT)<br /> pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs]<br /> lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs]<br /> sp : ffff8000838b3920<br /> x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810<br /> x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000<br /> x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020<br /> x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344<br /> x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000<br /> x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418<br /> x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d<br /> x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80<br /> Call trace:<br /> usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P)<br /> usbhsg_pullup+0x4c/0x7c [renesas_usbhs]<br /> usb_gadget_disconnect_locked+0x48/0xd4<br /> gadget_unbind_driver+0x44/0x114<br /> device_remove+0x4c/0x80<br /> device_release_driver_internal+0x1c8/0x224<br /> device_release_driver+0x18/0x24<br /> bus_remove_device+0xcc/0x10c<br /> device_del+0x14c/0x404<br /> usb_del_gadget+0x88/0xc0<br /> usb_del_gadget_udc+0x18/0x30<br /> usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs]<br /> usbhs_mod_remove+0x20/0x30 [renesas_usbhs]<br /> usbhs_remove+0x98/0xdc [renesas_usbhs]<br /> platform_remove+0x20/0x30<br /> device_remove+0x4c/0x80<br /> device_release_driver_internal+0x1c8/0x224<br /> device_driver_detach+0x18/0x24<br /> unbind_store+0xb4/0xb8<br /> drv_attr_store+0x24/0x38<br /> sysfs_kf_write+0x7c/0x94<br /> kernfs_fop_write_iter+0x128/0x1b8<br /> vfs_write+0x2ac/0x350<br /> ksys_write+0x68/0xfc<br /> __arm64_sys_write+0x1c/0x28<br /> invoke_syscall+0x48/0x110<br /> el0_svc_common.constprop.0+0xc0/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x34/0xf0<br /> el0t_64_sync_handler+0xa0/0xe4<br /> el0t_64_sync+0x198/0x19c<br /> Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021)<br /> ---[ end trace 0000000000000000 ]---<br /> note: sh[188] exited with irqs disabled<br /> note: sh[188] exited with preempt_count 1<br /> <br /> The issue occurs because usbhs_sys_function_pullup(), which accesses the IP<br /> registers, is executed after the USBHS clocks have been disabled. The<br /> problem is reproducible on the Renesas RZ/G3S SoC starting with the<br /> addition of module stop in the clock enable/disable APIs. With module stop<br /> functionality enabled, a bus error is expected if a master accesses a<br /> module whose clock has been stopped and module stop activated.<br /> <br /> Disable the IP clocks at the end of remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: stratix10-svc: fix bug in saving controller data<br /> <br /> Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They<br /> both are of the same data and overrides each other. This resulted in the<br /> rmmod of the svc driver to fail and throw a kernel panic for kthread_stop<br /> and fifo free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs<br /> <br /> When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel<br /> calls vm_ops-&gt;close on each portion. For trace buffer mappings, this<br /> results in ring_buffer_unmap() being called multiple times while<br /> ring_buffer_map() was only called once.<br /> <br /> This causes ring_buffer_unmap() to return -ENODEV on subsequent calls<br /> because user_mapped is already 0, triggering a WARN_ON.<br /> <br /> Trace buffer mappings cannot support partial mappings because the ring<br /> buffer structure requires the complete buffer including the meta page.<br /> <br /> Fix this by adding a may_split callback that returns -EINVAL to prevent<br /> VMA splits entirely.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: accel: bmc150: Fix irq assumption regression<br /> <br /> The code in bmc150-accel-core.c unconditionally calls<br /> bmc150_accel_set_interrupt() in the iio_buffer_setup_ops,<br /> such as on the runtime PM resume path giving a kernel<br /> splat like this if the device has no interrupts:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual<br /> address 00000001 when read<br /> <br /> PC is at bmc150_accel_set_interrupt+0x98/0x194<br /> LR is at __pm_runtime_resume+0x5c/0x64<br /> (...)<br /> Call trace:<br /> bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108<br /> bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc<br /> __iio_update_buffers from enable_store+0x84/0xc8<br /> enable_store from kernfs_fop_write_iter+0x154/0x1b4<br /> <br /> This bug seems to have been in the driver since the beginning,<br /> but it only manifests recently, I do not know why.<br /> <br /> Store the IRQ number in the state struct, as this is a common<br /> pattern in other drivers, then use this to determine if we have<br /> IRQ support or not.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer<br /> <br /> When a UAS device is unplugged during data transfer, there is<br /> a probability of a system panic occurring. The root cause is<br /> an access to an invalid memory address during URB callback handling.<br /> Specifically, this happens when the dma_direct_unmap_sg() function<br /> is called within the usb_hcd_unmap_urb_for_dma() interface, but the<br /> sg-&gt;dma_address field is 0 and the sg data structure has already been<br /> freed.<br /> <br /> The SCSI driver sends transfer commands by invoking uas_queuecommand_lck()<br /> in uas.c, using the uas_submit_urbs() function to submit requests to USB.<br /> Within the uas_submit_urbs() implementation, three URBs (sense_urb,<br /> data_urb, and cmd_urb) are sequentially submitted. Device removal may<br /> occur at any point during uas_submit_urbs execution, which may result<br /> in URB submission failure. However, some URBs might have been successfully<br /> submitted before the failure, and uas_submit_urbs will return the -ENODEV<br /> error code in this case. The current error handling directly calls<br /> scsi_done(). In the SCSI driver, this eventually triggers scsi_complete()<br /> to invoke scsi_end_request() for releasing the sgtable. The successfully<br /> submitted URBs, when being unlinked to giveback, call<br /> usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg<br /> unmapping operations since the sg data structure has already been freed.<br /> <br /> This patch modifies the error condition check in the uas_submit_urbs()<br /> function. When a UAS device is removed but one or more URBs have already<br /> been successfully submitted to USB, it avoids immediately invoking<br /> scsi_done() and save the cmnd to devinfo-&gt;cmnd array. If the successfully<br /> submitted URBs is completed before devinfo-&gt;resetting being set, then<br /> the scsi_done() function will be called within uas_try_complete() after<br /> all pending URB operations are finalized. Otherwise, the scsi_done()<br /> function will be called within uas_zap_pending(), which is executed after<br /> usb_kill_anchored_urbs().<br /> <br /> The error handling only takes effect when uas_queuecommand_lck() calls<br /> uas_submit_urbs() and returns the error value -ENODEV . In this case,<br /> the device is disconnected, and the flow proceeds to uas_disconnect(),<br /> where uas_zap_pending() is invoked to call uas_try_complete().