Vulnerabilidades

*** Pendiente de traducción *** MyNET up to v26.08 was discovered to contain a Reflected cross-site scripting (XSS) vulnerability via the msgtipo parameter.

*** Pendiente de traducción *** MyNET up to v26.05 was discovered to contain a reflected cross-site scripting (XSS) vulnerability via the msg parameter.

*** Pendiente de traducción *** A Local File Inclusion (LFI) vulnerability exists in the Webmail Classic UI of Zimbra Collaboration (ZCS) 10.0 and 10.1 because of improper handling of user-supplied request parameters in the RestFilter servlet. An unauthenticated remote attacker can craft requests to the /h/rest endpoint to influence internal request dispatching, allowing inclusion of arbitrary files from the WebRoot directory.

*** Pendiente de traducción *** An arbitrary file upload vulnerability in the Attachments module of Frappe Framework v15.89.0 allows attackers to execute arbitrary code via uploading a crafted XML file.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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 /> ...

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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.