| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Testa Online Test Management System 3.4.7 contains a SQL injection vulnerability that allows attackers to manipulate database queries through the 'q' search parameter. Attackers can inject malicious SQL code in the search field to extract database information, potentially accessing sensitive user or system data. |
| The web application is not protected against cross-site request forgery attacks. Therefore, an attacker can trick users into performing actions on the application when they visit an attacker-controlled website or click on a malicious link. E.g. an attacker can forge malicious links to reset the admin password or create new users. |
| A vulnerability has been identified in COMOS V10.6 (All versions < V10.6.1), COMOS V10.6 (All versions < V10.6.1), JT Bi-Directional Translator for STEP (All versions), NX V2412 (All versions < V2412.8900 with Cloud Entitlement (bundled as NX X)), NX V2506 (All versions < V2506.6000 with Cloud Entitlement (bundled as NX X)), Simcenter 3D (All versions < V2506.6000 with Cloud Entitlement (bundled as Simcenter X Mechanical)), Simcenter Femap (All versions < V2506.0002 with Cloud Entitlement (bundled as Simcenter X Mechanical)), Simcenter Studio (All versions < V2506.0001), Simcenter System Architect (All versions < V2506.0001), Tecnomatix Plant Simulation (All versions < V2504.0007). The SALT SDK is missing server certificate validation while establishing TLS connections to the authorization server. This could allow an attacker to perform a man-in-the-middle attack. |
| Improper Neutralization of Special Elements used in a Command ('Command Injection') vulnerability in Iocharger firmware for AC models allows OS Command Injection as root
This issue affects all Iocharger AC EV charger models on a firmware version before 25010801.
Likelihood: Moderate – The <redacted> binary does not seem to be used by the web interface, so it might be more difficult to find. It seems to be largely the same binary as used by the Iocharger Pedestal charging station, however. The attacker will also need a (low privilege) account to gain access to the <redacted> binary, or convince a user with such access to execute a crafted HTTP request.
Impact: Critical – The attacker has full control over the charging station as the root user, and can arbitrarily add, modify and delete
files and services.
CVSS clarification: Any network interface serving the web ui is vulnerable (AV:N) and there are not additional security measures to circumvent (AC:L), nor does the attack require and existing preconditions (AT:N). The attack is authenticated, but the level of authentication does not matter (PR:L), nor is any user interaction required (UI:N). The attack leads to a full compromised (VC:H/VI:H/VA:H), and compromised devices can be used to pivot into networks that should potentially not be accessible (SC:L/SI:L/SA:H). Becuase this is an EV charger handing significant power, there is a potential safety impact (S:P). This attack can be automated (AU:Y). |
| Improper neutralization of special elements used in an OS command ('OS Command Injection') issue exists in acmailer CGI ver.4.0.3 and earlier and acmailer DB ver.1.1.5 and earlier. If this vulnerability is exploited, an arbitrary OS command may be executed by an attacker. |
| A vulnerability has been identified in COMOS V10.6 (All versions < V10.6.1), COMOS V10.6 (All versions < V10.6.1), NX V2412 (All versions < V2412.8700), NX V2506 (All versions < V2506.6000), Simcenter 3D (All versions < V2506.6000), Simcenter Femap (All versions < V2506.0002), Solid Edge SE2025 (All versions < V225.0 Update 10), Solid Edge SE2026 (All versions < V226.0 Update 1). The IAM client in affected products is missing server certificate validation while establishing TLS connections to the authorization server. This could allow an attacker to perform a man-in-the-middle attack. |
| An issue in the component /internals/functions of R-fx Networks Linux Malware Detect v1.6.5 allows attackers to escalate privileges and execute arbitrary code via supplying a file that contains a crafted filename. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: Intel: avs: Disable periods-elapsed work when closing PCM
avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio
stream while period-elapsed work services its IRQs. As the former
frees the DAI's private context, these two operations shall be
synchronized to avoid slab-use-after-free or worse errors. |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet-fc: avoid scheduling association deletion twice
When forcefully shutting down a port via the configfs interface,
nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and
then nvmet_disable_port(). Both functions will eventually schedule all
remaining associations for deletion.
The current implementation checks whether an association is about to be
removed, but only after the work item has already been scheduled. As a
result, it is possible for the first scheduled work item to free all
resources, and then for the same work item to be scheduled again for
deletion.
Because the association list is an RCU list, it is not possible to take
a lock and remove the list entry directly, so it cannot be looked up
again. Instead, a flag (terminating) must be used to determine whether
the association is already in the process of being deleted. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Fix oops in xe_gem_fault when running core_hotunplug test.
I saw an oops in xe_gem_fault when running the xe-fast-feedback
testlist against the realtime kernel without debug options enabled.
The panic happens after core_hotunplug unbind-rebind finishes.
Presumably what happens is that a process mmaps, unlocks because
of the FAULT_FLAG_RETRY_NOWAIT logic, has no process memory left,
causing ttm_bo_vm_dummy_page() to return VM_FAULT_NOPAGE, since
there was nothing left to populate, and then oopses in
"mem_type_is_vram(tbo->resource->mem_type)" because tbo->resource
is NULL.
It's convoluted, but fits the data and explains the oops after
the test exits. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix nullptr err of vm_handle_moved
If a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL.
So, such kind of amdgpu_bo_va should be updated separately before
amdgpu_vm_handle_moved. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: Intel: avs: Do not share the name pointer between components
By sharing 'name' directly, tearing down components may lead to
use-after-free errors. Duplicate the name to avoid that.
At the same time, update the order of operations - since commit
cee28113db17 ("ASoC: dmaengine_pcm: Allow passing component name via
config") the framework does not override component->name if set before
invoking the initializer. |
| Out-of-bounds vulnerability in slope processing during curve rendering in Generic PCL6 V4 Printer Driver / Generic UFR II V4 Printer Driver / Generic LIPSLX V4 Printer Driver. |
| In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: Correctly handle Rx checksum offload errors
The stmmac_rx function would previously set skb->ip_summed to
CHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabled
and the packet was of a known IP ethertype.
However, this logic failed to check if the hardware had actually
reported a checksum error. The hardware status, indicating a header or
payload checksum failure, was being ignored at this stage. This could
cause corrupt packets to be passed up the network stack as valid.
This patch corrects the logic by checking the `csum_none` status flag,
which is set when the hardware reports a checksum error. If this flag
is set, skb->ip_summed is now correctly set to CHECKSUM_NONE,
ensuring the kernel's network stack will perform its own validation and
properly handle the corrupt packet. |
| Kottster is a self hosted Node.js admin panel. From versions 3.2.0 to before 3.3.2, Kottster contains a pre-authentication remote code execution (RCE) vulnerability when running in development mode. This affects development mode only, production deployments were never affected. This issue has been fixed in version 3.3.2. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/gpusvm: fix hmm_pfn_to_map_order() usage
Handle the case where the hmm range partially covers a huge page (like
2M), otherwise we can potentially end up doing something nasty like
mapping memory which is outside the range, and maybe not even mapped by
the mm. Fix is based on the xe userptr code, which in a future patch
will directly use gpusvm, so needs alignment here.
v2:
- Add kernel-doc (Matt B)
- s/fls/ilog2/ (Thomas) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: validate userq buffer virtual address and size
It needs to validate the userq object virtual address to
determine whether it is residented in a valid vm mapping. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb
The Mesa issue referenced below pointed out a possible deadlock:
[ 1231.611031] Possible interrupt unsafe locking scenario:
[ 1231.611033] CPU0 CPU1
[ 1231.611034] ---- ----
[ 1231.611035] lock(&xa->xa_lock#17);
[ 1231.611038] local_irq_disable();
[ 1231.611039] lock(&fence->lock);
[ 1231.611041] lock(&xa->xa_lock#17);
[ 1231.611044] <Interrupt>
[ 1231.611045] lock(&fence->lock);
[ 1231.611047]
*** DEADLOCK ***
In this example, CPU0 would be any function accessing job->dependencies
through the xa_* functions that don't disable interrupts (eg:
drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).
CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling
callback so in an interrupt context. It will deadlock when trying to
grab the xa_lock which is already held by CPU0.
Replacing all xa_* usage by their xa_*_irq counterparts would fix
this issue, but Christian pointed out another issue: dma_fence_signal
takes fence.lock and so does dma_fence_add_callback.
dma_fence_signal() // locks f1.lock
-> drm_sched_entity_kill_jobs_cb()
-> foreach dependencies
-> dma_fence_add_callback() // locks f2.lock
This will deadlock if f1 and f2 share the same spinlock.
To fix both issues, the code iterating on dependencies and re-arming them
is moved out to drm_sched_entity_kill_jobs_work().
[phasta: commit message nits] |
| An incorrect permission assignment for a critical resource vulnerability was discovered in Productivity Suite software version 4.4.1.19. The vulnerability allows an attacker with low-privileged credentials to change their role, gaining full control access to the project. |
| Utilizing default credentials, an attacker is able to log into the camera's operating system which could allow changes to be made to the operations or shutdown the camera requiring a physical reboot of the system. |
