Vulnerabilities

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 /> 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 /> 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 /> 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 /> 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 /> 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 /> bpf: Add the missing BPF_LINK_TYPE invocation for sockmap<br /> <br /> There is an out-of-bounds read in bpf_link_show_fdinfo() for the sockmap<br /> link fd. Fix it by adding the missing BPF_LINK_TYPE invocation for<br /> sockmap link<br /> <br /> Also add comments for bpf_link_type to prevent missing updates in the<br /> future.

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 /> netfilter: bpf: must hold reference on net namespace<br /> <br /> BUG: KASAN: slab-use-after-free in __nf_unregister_net_hook+0x640/0x6b0<br /> Read of size 8 at addr ffff8880106fe400 by task repro/72=<br /> bpf_nf_link_release+0xda/0x1e0<br /> bpf_link_free+0x139/0x2d0<br /> bpf_link_release+0x68/0x80<br /> __fput+0x414/0xb60<br /> <br /> Eric says:<br /> It seems that bpf was able to defer the __nf_unregister_net_hook()<br /> after exit()/close() time.<br /> Perhaps a netns reference is missing, because the netns has been<br /> dismantled/freed already.<br /> bpf_nf_link_attach() does :<br /> link-&gt;net = net;<br /> But I do not see a reference being taken on net.<br /> <br /> Add such a reference and release it after hook unreg.<br /> Note that I was unable to get syzbot reproducer to work, so I<br /> do not know if this resolves this splat.

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 /> smb: client: Handle kstrdup failures for passwords<br /> <br /> In smb3_reconfigure(), after duplicating ctx-&gt;password and<br /> ctx-&gt;password2 with kstrdup(), we need to check for allocation<br /> failures.<br /> <br /> If ses-&gt;password allocation fails, return -ENOMEM.<br /> If ses-&gt;password2 allocation fails, free ses-&gt;password, set it<br /> to NULL, and return -ENOMEM.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net<br /> <br /> In the normal case, when we excute `echo 0 &gt; /proc/fs/nfsd/threads`, the<br /> function `nfs4_state_destroy_net` in `nfs4_state_shutdown_net` will<br /> release all resources related to the hashed `nfs4_client`. If the<br /> `nfsd_client_shrinker` is running concurrently, the `expire_client`<br /> function will first unhash this client and then destroy it. This can<br /> lead to the following warning. Additionally, numerous use-after-free<br /> errors may occur as well.<br /> <br /> nfsd_client_shrinker echo 0 &gt; /proc/fs/nfsd/threads<br /> <br /> expire_client nfsd_shutdown_net<br /> unhash_client ...<br /> nfs4_state_shutdown_net<br /> /* won&amp;#39;t wait shrinker exit */<br /> /* cancel_work(&amp;nn-&gt;nfsd_shrinker_work)<br /> * nfsd_file for this /* won&amp;#39;t destroy unhashed client1 */<br /> * client1 still alive nfs4_state_destroy_net<br /> */<br /> <br /> nfsd_file_cache_shutdown<br /> /* trigger warning */<br /> kmem_cache_destroy(nfsd_file_slab)<br /> kmem_cache_destroy(nfsd_file_mark_slab)<br /> /* release nfsd_file and mark */<br /> __destroy_client<br /> <br /> ====================================================================<br /> BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on<br /> __kmem_cache_shutdown()<br /> --------------------------------------------------------------------<br /> CPU: 4 UID: 0 PID: 764 Comm: sh Not tainted 6.12.0-rc3+ #1<br /> <br /> dump_stack_lvl+0x53/0x70<br /> slab_err+0xb0/0xf0<br /> __kmem_cache_shutdown+0x15c/0x310<br /> kmem_cache_destroy+0x66/0x160<br /> nfsd_file_cache_shutdown+0xac/0x210 [nfsd]<br /> nfsd_destroy_serv+0x251/0x2a0 [nfsd]<br /> nfsd_svc+0x125/0x1e0 [nfsd]<br /> write_threads+0x16a/0x2a0 [nfsd]<br /> nfsctl_transaction_write+0x74/0xa0 [nfsd]<br /> vfs_write+0x1a5/0x6d0<br /> ksys_write+0xc1/0x160<br /> do_syscall_64+0x5f/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> ====================================================================<br /> BUG nfsd_file_mark (Tainted: G B W ): Objects remaining<br /> nfsd_file_mark on __kmem_cache_shutdown()<br /> --------------------------------------------------------------------<br /> <br /> dump_stack_lvl+0x53/0x70<br /> slab_err+0xb0/0xf0<br /> __kmem_cache_shutdown+0x15c/0x310<br /> kmem_cache_destroy+0x66/0x160<br /> nfsd_file_cache_shutdown+0xc8/0x210 [nfsd]<br /> nfsd_destroy_serv+0x251/0x2a0 [nfsd]<br /> nfsd_svc+0x125/0x1e0 [nfsd]<br /> write_threads+0x16a/0x2a0 [nfsd]<br /> nfsctl_transaction_write+0x74/0xa0 [nfsd]<br /> vfs_write+0x1a5/0x6d0<br /> ksys_write+0xc1/0x160<br /> do_syscall_64+0x5f/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> To resolve this issue, cancel `nfsd_shrinker_work` using synchronous<br /> mode in nfs4_state_shutdown_net.