Vulnerabilities

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().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: c6xdigio: Fix invalid PNP driver unregistration<br /> <br /> The Comedi low-level driver "c6xdigio" seems to be for a parallel port<br /> connected device. When the Comedi core calls the driver&amp;#39;s Comedi<br /> "attach" handler `c6xdigio_attach()` to configure a Comedi to use this<br /> driver, it tries to enable the parallel port PNP resources by<br /> registering a PNP driver with `pnp_register_driver()`, but ignores the<br /> return value. (The `struct pnp_driver` it uses has only the `name` and<br /> `id_table` members filled in.) The driver&amp;#39;s Comedi "detach" handler<br /> `c6xdigio_detach()` unconditionally unregisters the PNP driver with<br /> `pnp_unregister_driver()`.<br /> <br /> It is possible for `c6xdigio_attach()` to return an error before it<br /> calls `pnp_register_driver()` and it is possible for the call to<br /> `pnp_register_driver()` to return an error (that is ignored). In both<br /> cases, the driver should not be calling `pnp_unregister_driver()` as it<br /> does in `c6xdigio_detach()`. (Note that `c6xdigio_detach()` will be<br /> called by the Comedi core if `c6xdigio_attach()` returns an error, or if<br /> the Comedi core decides to detach the Comedi device from the driver for<br /> some other reason.)<br /> <br /> The unconditional call to `pnp_unregister_driver()` without a previous<br /> successful call to `pnp_register_driver()` will cause<br /> `driver_unregister()` to issue a warning "Unexpected driver<br /> unregister!". This was detected by Syzbot [1].<br /> <br /> Also, the PNP driver registration and unregistration should be done at<br /> module init and exit time, respectively, not when attaching or detaching<br /> Comedi devices to the driver. (There might be more than one Comedi<br /> device being attached to the driver, although that is unlikely.)<br /> <br /> Change the driver to do the PNP driver registration at module init time,<br /> and the unregistration at module exit time. Since `c6xdigio_detach()`<br /> now only calls `comedi_legacy_detach()`, remove the function and change<br /> the Comedi driver "detach" handler to `comedi_legacy_detach`.<br /> <br /> -------------------------------------------<br /> [1] Syzbot sample crash report:<br /> Unexpected driver unregister!<br /> WARNING: CPU: 0 PID: 5970 at drivers/base/driver.c:273 driver_unregister drivers/base/driver.c:273 [inline]<br /> WARNING: CPU: 0 PID: 5970 at drivers/base/driver.c:273 driver_unregister+0x90/0xb0 drivers/base/driver.c:270<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 5970 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025<br /> RIP: 0010:driver_unregister drivers/base/driver.c:273 [inline]<br /> RIP: 0010:driver_unregister+0x90/0xb0 drivers/base/driver.c:270<br /> Code: 48 89 ef e8 c2 e6 82 fc 48 89 df e8 3a 93 ff ff 5b 5d e9 c3 6d d9 fb e8 be 6d d9 fb 90 48 c7 c7 e0 f8 1f 8c e8 51 a2 97 fb 90 0b 90 90 5b 5d e9 a5 6d d9 fb e8 e0 f4 41 fc eb 94 e8 d9 f4 41<br /> RSP: 0018:ffffc9000373f9a0 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffffffff8ff24720 RCX: ffffffff817b6ee8<br /> RDX: ffff88807c932480 RSI: ffffffff817b6ef5 RDI: 0000000000000001<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffffffff8ff24660<br /> R13: dffffc0000000000 R14: 0000000000000000 R15: ffff88814cca0000<br /> FS: 000055556dab1500(0000) GS:ffff8881249d9000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055f77f285cd0 CR3: 000000007d871000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> comedi_device_detach_locked+0x12f/0xa50 drivers/comedi/drivers.c:207<br /> comedi_device_detach+0x67/0xb0 drivers/comedi/drivers.c:215<br /> comedi_device_attach+0x43d/0x900 drivers/comedi/drivers.c:1011<br /> do_devconfig_ioctl+0x1b1/0x710 drivers/comedi/comedi_fops.c:872<br /> comedi_unlocked_ioctl+0x165d/0x2f00 drivers/comedi/comedi_fops.c:2178<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl fs/ioctl.c:583 [inline]<br /> __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_sys<br /> ---truncated---

Schlix CMS before v2.2.9-5 is vulnerable to Cross Site Scripting (XSS). Due to lack of javascript sanitization in the login form, incorrect login attempts in logs are triggered as XSS in the admin panel.

A Use of Uninitialized Variable vulnerability exists in Open Design Alliance Drawings SDK static versions (mt) before 2026.12. Static object `COdaMfcAppApp theApp` may access `OdString::kEmpty` before its initialization. Due to undefined initialization order of static objects across translation units (Static Initialization Order Fiasco), the application accesses uninitialized memory. This results in application crash on startup, causing denial of service. Due to undefined behavior,  memory corruption and potential arbitrary code execution cannot be ruled out in specific exploitation scenarios.

Use of a weak pseudo-random number generator, which may allow an attacker to read or inject encrypted PowerG packets.

Authentication issue that does not verify the source of a packet which could allow an attacker to create a denial-of-service condition or modify the configuration of the device.

An issue was discovered in K7 Ultimate Security 17.0.2045. A Local Privilege Escalation (LPE) vulnerability in the K7 Ultimate Security antivirus can be exploited by a local unprivileged user on default installations of the product. Insecure access to a named pipe allows unprivileged users to edit any registry key, leading to a full compromise as SYSTEM.

Unquoted Search Path or Element vulnerability in NetBT Consulting Services Inc. E-Fatura allows Leveraging/Manipulating Configuration File Search Paths, Redirect Access to Libraries.This issue affects e-Fatura: before 1.2.15.