Vulnerabilities

A vulnerability has been identified in Gridscale X Prepay (All versions

A vulnerability has been identified in COMOS V10.6 (All versions), COMOS V10.6 (All versions), NX V2412 (All versions

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

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.

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.

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.

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.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-fc: avoid scheduling association deletion twice<br /> <br /> When forcefully shutting down a port via the configfs interface,<br /> nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and<br /> then nvmet_disable_port(). Both functions will eventually schedule all<br /> remaining associations for deletion.<br /> <br /> The current implementation checks whether an association is about to be<br /> removed, but only after the work item has already been scheduled. As a<br /> result, it is possible for the first scheduled work item to free all<br /> resources, and then for the same work item to be scheduled again for<br /> deletion.<br /> <br /> Because the association list is an RCU list, it is not possible to take<br /> a lock and remove the list entry directly, so it cannot be looked up<br /> again. Instead, a flag (terminating) must be used to determine whether<br /> the association is already in the process of being deleted.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: avs: Disable periods-elapsed work when closing PCM<br /> <br /> avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio<br /> stream while period-elapsed work services its IRQs. As the former<br /> frees the DAI&amp;#39;s private context, these two operations shall be<br /> synchronized to avoid slab-use-after-free or worse errors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb<br /> <br /> The Mesa issue referenced below pointed out a possible deadlock:<br /> <br /> [ 1231.611031] Possible interrupt unsafe locking scenario:<br /> <br /> [ 1231.611033] CPU0 CPU1<br /> [ 1231.611034] ---- ----<br /> [ 1231.611035] lock(&amp;xa-&gt;xa_lock#17);<br /> [ 1231.611038] local_irq_disable();<br /> [ 1231.611039] lock(&amp;fence-&gt;lock);<br /> [ 1231.611041] lock(&amp;xa-&gt;xa_lock#17);<br /> [ 1231.611044] <br /> [ 1231.611045] lock(&amp;fence-&gt;lock);<br /> [ 1231.611047]<br /> *** DEADLOCK ***<br /> <br /> In this example, CPU0 would be any function accessing job-&gt;dependencies<br /> through the xa_* functions that don&amp;#39;t disable interrupts (eg:<br /> drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).<br /> <br /> CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling<br /> callback so in an interrupt context. It will deadlock when trying to<br /> grab the xa_lock which is already held by CPU0.<br /> <br /> Replacing all xa_* usage by their xa_*_irq counterparts would fix<br /> this issue, but Christian pointed out another issue: dma_fence_signal<br /> takes fence.lock and so does dma_fence_add_callback.<br /> <br /> dma_fence_signal() // locks f1.lock<br /> -&gt; drm_sched_entity_kill_jobs_cb()<br /> -&gt; foreach dependencies<br /> -&gt; dma_fence_add_callback() // locks f2.lock<br /> <br /> This will deadlock if f1 and f2 share the same spinlock.<br /> <br /> To fix both issues, the code iterating on dependencies and re-arming them<br /> is moved out to drm_sched_entity_kill_jobs_work().<br /> <br /> [phasta: commit message nits]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Shutdown FW DMA in bnxt_shutdown()<br /> <br /> The netif_close() call in bnxt_shutdown() only stops packet DMA. There<br /> may be FW DMA for trace logging (recently added) that will continue. If<br /> we kexec to a new kernel, the DMA will corrupt memory in the new kernel.<br /> <br /> Add bnxt_hwrm_func_drv_unrgtr() to unregister the driver from the FW.<br /> This will stop the FW DMA. In case the call fails, call pcie_flr() to<br /> reset the function and stop the DMA.