Vulnerabilidades

*** Pendiente de traducción *** A vulnerability has been identified in SINEC Security Monitor (All versions

*** Pendiente de traducción *** A vulnerability has been identified in SINEMA Remote Connect Server (All versions

*** Pendiente de traducción *** A vulnerability has been identified in SINEMA Remote Connect Server (All versions

*** Pendiente de traducción *** A vulnerability has been identified in Gridscale X Prepay (All versions

*** Pendiente de traducción *** A vulnerability has been identified in Gridscale X Prepay (All versions

*** Pendiente de traducción *** A vulnerability has been identified in COMOS V10.6 (All versions), COMOS V10.6 (All versions), NX V2412 (All versions

*** Pendiente de traducción *** A vulnerability has been identified in COMOS V10.6 (All versions), COMOS V10.6 (All versions), JT Bi-Directional Translator for STEP (All versions), NX V2412 (All versions

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: avs: Do not share the name pointer between components<br /> <br /> By sharing &amp;#39;name&amp;#39; directly, tearing down components may lead to<br /> use-after-free errors. Duplicate the name to avoid that.<br /> <br /> At the same time, update the order of operations - since commit<br /> cee28113db17 ("ASoC: dmaengine_pcm: Allow passing component name via<br /> config") the framework does not override component-&gt;name if set before<br /> invoking the initializer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix nullptr err of vm_handle_moved<br /> <br /> If a amdgpu_bo_va is fpriv-&gt;prt_va, the bo of this one is always NULL.<br /> So, such kind of amdgpu_bo_va should be updated separately before<br /> amdgpu_vm_handle_moved.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix oops in xe_gem_fault when running core_hotunplug test.<br /> <br /> I saw an oops in xe_gem_fault when running the xe-fast-feedback<br /> testlist against the realtime kernel without debug options enabled.<br /> <br /> The panic happens after core_hotunplug unbind-rebind finishes.<br /> Presumably what happens is that a process mmaps, unlocks because<br /> of the FAULT_FLAG_RETRY_NOWAIT logic, has no process memory left,<br /> causing ttm_bo_vm_dummy_page() to return VM_FAULT_NOPAGE, since<br /> there was nothing left to populate, and then oopses in<br /> "mem_type_is_vram(tbo-&gt;resource-&gt;mem_type)" because tbo-&gt;resource<br /> is NULL.<br /> <br /> It&amp;#39;s convoluted, but fits the data and explains the oops after<br /> the test exits.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> futex: Don&amp;#39;t leak robust_list pointer on exec race<br /> <br /> sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()<br /> to check if the calling task is allowed to access another task&amp;#39;s<br /> robust_list pointer. This check is racy against a concurrent exec() in the<br /> target process.<br /> <br /> During exec(), a task may transition from a non-privileged binary to a<br /> privileged one (e.g., setuid binary) and its credentials/memory mappings<br /> may change. If get_robust_list() performs ptrace_may_access() before<br /> this transition, it may erroneously allow access to sensitive information<br /> after the target becomes privileged.<br /> <br /> A racy access allows an attacker to exploit a window during which<br /> ptrace_may_access() passes before a target process transitions to a<br /> privileged state via exec().<br /> <br /> For example, consider a non-privileged task T that is about to execute a<br /> setuid-root binary. An attacker task A calls get_robust_list(T) while T<br /> is still unprivileged. Since ptrace_may_access() checks permissions<br /> based on current credentials, it succeeds. However, if T begins exec<br /> immediately afterwards, it becomes privileged and may change its memory<br /> mappings. Because get_robust_list() proceeds to access T-&gt;robust_list<br /> without synchronizing with exec() it may read user-space pointers from a<br /> now-privileged process.<br /> <br /> This violates the intended post-exec access restrictions and could<br /> expose sensitive memory addresses or be used as a primitive in a larger<br /> exploit chain. Consequently, the race can lead to unauthorized<br /> disclosure of information across privilege boundaries and poses a<br /> potential security risk.<br /> <br /> Take a read lock on signal-&gt;exec_update_lock prior to invoking<br /> ptrace_may_access() and accessing the robust_list/compat_robust_list.<br /> This ensures that the target task&amp;#39;s exec state remains stable during the<br /> check, allowing for consistent and synchronized validation of<br /> credentials.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-fc: use lock accessing port_state and rport state<br /> <br /> nvme_fc_unregister_remote removes the remote port on a lport object at<br /> any point in time when there is no active association. This races with<br /> with the reconnect logic, because nvme_fc_create_association is not<br /> taking a lock to check the port_state and atomically increase the<br /> active count on the rport.