Vulnerabilities

OctoPrint provides a web interface for controlling consumer 3D printers. OctoPrint versions up until and including 1.10.2 contain reflected XSS vulnerabilities in the login dialog and the standalone application key confirmation dialog. An attacker who successfully talked a victim into clicking on a specially crafted login link, or a malicious app running on a victim's computer triggering the application key workflow with specially crafted parameters and then redirecting the victim to the related standalone confirmation dialog could use this to retrieve or modify sensitive configuration settings, interrupt prints or otherwise interact with the OctoPrint instance in a malicious way. The above mentioned specific vulnerabilities of the login dialog and the standalone application key confirmation dialog have been patched in the bugfix release 1.10.3 by individual escaping of the detected locations. A global change throughout all of OctoPrint's templating system with the upcoming 1.11.0 release will handle this further, switching to globally enforced automatic escaping and thus reducing the attack surface in general. The latter will also improve the security of third party plugins. During a transition period, third party plugins will be able to opt into the automatic escaping. With OctoPrint 1.13.0, automatic escaping will be switched over to be enforced even for third party plugins, unless they explicitly opt-out.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Don&amp;#39;t crash in stack_top() for tasks without vDSO<br /> <br /> Not all tasks have a vDSO mapped, for example kthreads never do. If such<br /> a task ever ends up calling stack_top(), it will derefence the NULL vdso<br /> pointer and crash.<br /> <br /> This can for example happen when using kunit:<br /> <br /> [] stack_top+0x58/0xa8<br /> [] arch_pick_mmap_layout+0x164/0x220<br /> [] kunit_vm_mmap_init+0x108/0x12c<br /> [] __kunit_add_resource+0x38/0x8c<br /> [] kunit_vm_mmap+0x88/0xc8<br /> [] usercopy_test_init+0xbc/0x25c<br /> [] kunit_try_run_case+0x5c/0x184<br /> [] kunit_generic_run_threadfn_adapter+0x24/0x48<br /> [] kthread+0xc8/0xd4<br /> [] ret_from_kernel_thread+0xc/0xa4

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Unregister notifier on eswitch init failure<br /> <br /> It otherwise remains registered and a subsequent attempt at eswitch<br /> enabling might trigger warnings of the sort:<br /> <br /> [ 682.589148] ------------[ cut here ]------------<br /> [ 682.590204] notifier callback eswitch_vport_event [mlx5_core] already registered<br /> [ 682.590256] WARNING: CPU: 13 PID: 2660 at kernel/notifier.c:31 notifier_chain_register+0x3e/0x90<br /> [...snipped]<br /> [ 682.610052] Call Trace:<br /> [ 682.610369] <br /> [ 682.610663] ? __warn+0x7c/0x110<br /> [ 682.611050] ? notifier_chain_register+0x3e/0x90<br /> [ 682.611556] ? report_bug+0x148/0x170<br /> [ 682.611977] ? handle_bug+0x36/0x70<br /> [ 682.612384] ? exc_invalid_op+0x13/0x60<br /> [ 682.612817] ? asm_exc_invalid_op+0x16/0x20<br /> [ 682.613284] ? notifier_chain_register+0x3e/0x90<br /> [ 682.613789] atomic_notifier_chain_register+0x25/0x40<br /> [ 682.614322] mlx5_eswitch_enable_locked+0x1d4/0x3b0 [mlx5_core]<br /> [ 682.614965] mlx5_eswitch_enable+0xc9/0x100 [mlx5_core]<br /> [ 682.615551] mlx5_device_enable_sriov+0x25/0x340 [mlx5_core]<br /> [ 682.616170] mlx5_core_sriov_configure+0x50/0x170 [mlx5_core]<br /> [ 682.616789] sriov_numvfs_store+0xb0/0x1b0<br /> [ 682.617248] kernfs_fop_write_iter+0x117/0x1a0<br /> [ 682.617734] vfs_write+0x231/0x3f0<br /> [ 682.618138] ksys_write+0x63/0xe0<br /> [ 682.618536] do_syscall_64+0x4c/0x100<br /> [ 682.618958] entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: fix race condition between reset and nvme_dev_disable()<br /> <br /> nvme_dev_disable() modifies the dev-&gt;online_queues field, therefore<br /> nvme_pci_update_nr_queues() should avoid racing against it, otherwise<br /> we could end up passing invalid values to blk_mq_update_nr_hw_queues().<br /> <br /> WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347<br /> pci_irq_get_affinity+0x187/0x210<br /> Workqueue: nvme-reset-wq nvme_reset_work [nvme]<br /> RIP: 0010:pci_irq_get_affinity+0x187/0x210<br /> Call Trace:<br /> <br /> ? blk_mq_pci_map_queues+0x87/0x3c0<br /> ? pci_irq_get_affinity+0x187/0x210<br /> blk_mq_pci_map_queues+0x87/0x3c0<br /> nvme_pci_map_queues+0x189/0x460 [nvme]<br /> blk_mq_update_nr_hw_queues+0x2a/0x40<br /> nvme_reset_work+0x1be/0x2a0 [nvme]<br /> <br /> Fix the bug by locking the shutdown_lock mutex before using<br /> dev-&gt;online_queues. Give up if nvme_dev_disable() is running or if<br /> it has been executed already.

Combodo iTop is a simple, web based IT Service Management tool. Unauthenticated user can perform users enumeration, which can make it easier to bruteforce a valid account. As a fix the sentence displayed after resetting password no longer shows if the user exists or not. This fix is included in versions 2.7.11, 3.0.5, 3.1.2, and 3.2.0. Users are advised to upgrade. Users unable to upgrade may overload the dictionary entry `"UI:ResetPwd-Error-WrongLogin"` through an extension and replace it with a generic message.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA<br /> <br /> Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with<br /> a real VLA to fix a "memcpy: detected field-spanning write error" warning:<br /> <br /> [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p-&gt;data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4)<br /> [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo]<br /> [ 13.320038] Call Trace:<br /> [ 13.320173] hgsmi_update_pointer_shape [vboxvideo]<br /> [ 13.320184] vbox_cursor_atomic_update [vboxvideo]<br /> <br /> Note as mentioned in the added comment it seems the original length<br /> calculation for the allocated and send hgsmi buffer is 4 bytes too large.<br /> Changing this is not the goal of this patch, so this behavior is kept.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Use raw_spinlock_t in ringbuf<br /> <br /> The function __bpf_ringbuf_reserve is invoked from a tracepoint, which<br /> disables preemption. Using spinlock_t in this context can lead to a<br /> "sleep in atomic" warning in the RT variant. This issue is illustrated<br /> in the example below:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 1, expected: 1<br /> INFO: lockdep is turned off.<br /> Preemption disabled at:<br /> [] migrate_enable+0xc0/0x39c<br /> CPU: 7 PID: 556208 Comm: test_progs Tainted: G<br /> Hardware name: Qualcomm SA8775P Ride (DT)<br /> Call trace:<br /> dump_backtrace+0xac/0x130<br /> show_stack+0x1c/0x30<br /> dump_stack_lvl+0xac/0xe8<br /> dump_stack+0x18/0x30<br /> __might_resched+0x3bc/0x4fc<br /> rt_spin_lock+0x8c/0x1a4<br /> __bpf_ringbuf_reserve+0xc4/0x254<br /> bpf_ringbuf_reserve_dynptr+0x5c/0xdc<br /> bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238<br /> trace_call_bpf+0x238/0x774<br /> perf_call_bpf_enter.isra.0+0x104/0x194<br /> perf_syscall_enter+0x2f8/0x510<br /> trace_sys_enter+0x39c/0x564<br /> syscall_trace_enter+0x220/0x3c0<br /> do_el0_svc+0x138/0x1dc<br /> el0_svc+0x54/0x130<br /> el0t_64_sync_handler+0x134/0x150<br /> el0t_64_sync+0x17c/0x180<br /> <br /> Switch the spinlock to raw_spinlock_t to avoid this error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC<br /> <br /> data-&gt;asserted will be NULL on JH7110 SoC since commit 82327b127d41<br /> ("reset: starfive: Add StarFive JH7110 reset driver") was added. Add<br /> the judgment condition to avoid errors when calling reset_control_status<br /> on JH7110 SoC.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Hold rescan lock while adding devices during host probe<br /> <br /> Since adding the PCI power control code, we may end up with a race between<br /> the pwrctl platform device rescanning the bus and host controller probe<br /> functions. The latter need to take the rescan lock when adding devices or<br /> we may end up in an undefined state having two incompletely added devices<br /> and hit the following crash when trying to remove the device over sysfs:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> Call trace:<br /> __pi_strlen+0x14/0x150<br /> kernfs_find_ns+0x80/0x13c<br /> kernfs_remove_by_name_ns+0x54/0xf0<br /> sysfs_remove_bin_file+0x24/0x34<br /> pci_remove_resource_files+0x3c/0x84<br /> pci_remove_sysfs_dev_files+0x28/0x38<br /> pci_stop_bus_device+0x8c/0xd8<br /> pci_stop_bus_device+0x40/0xd8<br /> pci_stop_and_remove_bus_device_locked+0x28/0x48<br /> remove_store+0x70/0xb0<br /> dev_attr_store+0x20/0x38<br /> sysfs_kf_write+0x58/0x78<br /> kernfs_fop_write_iter+0xe8/0x184<br /> vfs_write+0x2dc/0x308<br /> ksys_write+0x7c/0xec

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/probes: Fix MAX_TRACE_ARGS limit handling<br /> <br /> When creating a trace_probe we would set nr_args prior to truncating the<br /> arguments to MAX_TRACE_ARGS. However, we would only initialize arguments<br /> up to the limit.<br /> <br /> This caused invalid memory access when attempting to set up probes with<br /> more than 128 fetchargs.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 0 UID: 0 PID: 1769 Comm: cat Not tainted 6.11.0-rc7+ #8<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014<br /> RIP: 0010:__set_print_fmt+0x134/0x330<br /> <br /> Resolve the issue by applying the MAX_TRACE_ARGS limit earlier. Return<br /> an error when there are too many arguments instead of silently<br /> truncating.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: pse-pd: Fix out of bound for loop<br /> <br /> Adjust the loop limit to prevent out-of-bounds access when iterating over<br /> PI structures. The loop should not reach the index pcdev-&gt;nr_lines since<br /> we allocate exactly pcdev-&gt;nr_lines number of PI structures. This fix<br /> ensures proper bounds are maintained during iterations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Consider the NULL character when validating the event length<br /> <br /> strlen() returns a string length excluding the null byte. If the string<br /> length equals to the maximum buffer length, the buffer will have no<br /> space for the NULL terminating character.<br /> <br /> This commit checks this condition and returns failure for it.