Vulnerabilidades

*** Pendiente de traducción *** OpenSTAManager is an open source management software for technical assistance and invoicing. In version 2.9.8 and prior, there is a SQL Injection vulnerability in the Stampe Module. At time of publication, no known patch exists.

*** Pendiente de traducción *** n8n is an open source workflow automation platform. Prior to versions 1.123.18 and 2.5.0, a vulnerability in the file access controls allows authenticated users with permission to create or modify workflows to read sensitive files from the n8n host system. This can be exploited to obtain critical configuration data and user credentials, leading to complete account takeover of any user on the instance. This issue has been patched in versions 1.123.18 and 2.5.0.

*** Pendiente de traducción *** n8n is an open source workflow automation platform. Prior to versions 1.123.10 and 2.5.0, vulnerabilities in the Git node allowed authenticated users with permission to create or modify workflows to execute arbitrary system commands or read arbitrary files on the n8n host. This issue has been patched in versions 1.123.10 and 2.5.0.

*** Pendiente de traducción *** n8n is an open source workflow automation platform. Prior to versions 1.123.9 and 2.2.1, a Cross-Site Scripting (XSS) vulnerability existed in a markdown rendering component used in n8n's interface, including workflow sticky notes and other areas that support markdown content. An authenticated user with permission to create or modify workflows could abuse this to execute scripts with same-origin privileges when other users interact with a maliciously crafted workflow. This could lead to session hijacking and account takeover. This issue has been patched in versions 1.123.9 and 2.2.1.

*** Pendiente de traducción *** n8n is an open source workflow automation platform. Prior to versions 1.123.12 and 2.4.0, when workflows process uploaded files and transfer them to remote servers via the SSH node without validating their metadata the vulnerability can lead to files being written to unintended locations on those remote systems potentially leading to remote code execution on those systems. As a prerequisites an unauthenticated attacker needs knowledge of such workflows existing and the endpoints for file uploads need to be unauthenticated. This issue has been patched in versions 1.123.12 and 2.4.0.

*** Pendiente de traducción *** n8n is an open source workflow automation platform. Prior to versions 1.118.0 and 2.4.0, a vulnerability in the Merge node's SQL Query mode allowed authenticated users with permission to create or modify workflows to write arbitrary files to the n8n server's filesystem potentially leading to remote code execution. This issue has been patched in versions 1.118.0 and 2.4.0.

*** Pendiente de traducción *** n8n is an open source workflow automation platform. Prior to version 2.4.8, a vulnerability in the Python Code node allows authenticated users to break out of the Python sandbox environment and execute code outside the intended security boundary. This issue has been patched in version 2.4.8.

*** Pendiente de traducción *** n8n is an open source workflow automation platform. Prior to versions 1.123.17 and 2.5.2, an authenticated user with permission to create or modify workflows could abuse crafted expressions in workflow parameters to trigger unintended system command execution on the host running n8n. This issue has been patched in versions 1.123.17 and 2.5.2.

*** Pendiente de traducción *** n8n is an open source workflow automation platform. Prior to version 1.123.2, a Cross-Site Scripting (XSS) vulnerability has been identified in the handling of webhook responses and related HTTP endpoints. Under certain conditions, the Content Security Policy (CSP) sandbox protection intended to isolate HTML responses may not be applied correctly. An authenticated user with permission to create or modify workflows could abuse this to execute malicious scripts with same-origin privileges when other users interact with the crafted workflow. This could lead to session hijacking and account takeover. This issue has been patched in version 1.123.2.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/fpsimd: signal: Fix restoration of SVE context<br /> <br /> When SME is supported, Restoring SVE signal context can go wrong in a<br /> few ways, including placing the task into an invalid state where the<br /> kernel may read from out-of-bounds memory (and may potentially take a<br /> fatal fault) and/or may kill the task with a SIGKILL.<br /> <br /> (1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into<br /> an invalid state where SVCR.SM is set (and sve_state is non-NULL)<br /> but TIF_SME is clear, consequently resuting in out-of-bounds memory<br /> reads and/or killing the task with SIGKILL.<br /> <br /> This can only occur in unusual (but legitimate) cases where the SVE<br /> signal context has either been modified by userspace or was saved in<br /> the context of another task (e.g. as with CRIU), as otherwise the<br /> presence of an SVE signal context with SVE_SIG_FLAG_SM implies that<br /> TIF_SME is already set.<br /> <br /> While in this state, task_fpsimd_load() will NOT configure SMCR_ELx<br /> (leaving some arbitrary value configured in hardware) before<br /> restoring SVCR and attempting to restore the streaming mode SVE<br /> registers from memory via sve_load_state(). As the value of<br /> SMCR_ELx.LEN may be larger than the task&amp;#39;s streaming SVE vector<br /> length, this may read memory outside of the task&amp;#39;s allocated<br /> sve_state, reading unrelated data and/or triggering a fault.<br /> <br /> While this can result in secrets being loaded into streaming SVE<br /> registers, these values are never exposed. As TIF_SME is clear,<br /> fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0<br /> accesses to streaming mode SVE registers, so these cannot be<br /> accessed directly at EL0. As fpsimd_save_user_state() verifies the<br /> live vector length before saving (S)SVE state to memory, no secret<br /> values can be saved back to memory (and hence cannot be observed via<br /> ptrace, signals, etc).<br /> <br /> When the live vector length doesn&amp;#39;t match the expected vector length<br /> for the task, fpsimd_save_user_state() will send a fatal SIGKILL<br /> signal to the task. Hence the task may be killed after executing<br /> userspace for some period of time.<br /> <br /> (2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the<br /> task&amp;#39;s SVCR.SM. If SVCR.SM was set prior to restoring the context,<br /> then the task will be left in streaming mode unexpectedly, and some<br /> register state will be combined inconsistently, though the task will<br /> be left in legitimate state from the kernel&amp;#39;s PoV.<br /> <br /> This can only occur in unusual (but legitimate) cases where ptrace<br /> has been used to set SVCR.SM after entry to the sigreturn syscall,<br /> as syscall entry clears SVCR.SM.<br /> <br /> In these cases, the the provided SVE register data will be loaded<br /> into the task&amp;#39;s sve_state using the non-streaming SVE vector length<br /> and the FPSIMD registers will be merged into this using the<br /> streaming SVE vector length.<br /> <br /> Fix (1) by setting TIF_SME when setting SVCR.SM. This also requires<br /> ensuring that the task&amp;#39;s sme_state has been allocated, but as this could<br /> contain live ZA state, it should not be zeroed. Fix (2) by clearing<br /> SVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.<br /> <br /> For consistency, I&amp;#39;ve pulled the manipulation of SVCR, TIF_SVE, TIF_SME,<br /> and fp_type earlier, immediately after the allocation of<br /> sve_state/sme_state, before the restore of the actual register state.<br /> This makes it easier to ensure that these are always modified<br /> consistently, even if a fault is taken while reading the register data<br /> from the signal context. I do not expect any software to depend on the<br /> exact state restored when a fault is taken while reading the context.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvlan: Make the addrs_lock be per port<br /> <br /> Make the addrs_lock be per port, not per ipvlan dev.<br /> <br /> Initial code seems to be written in the assumption,<br /> that any address change must occur under RTNL.<br /> But it is not so for the case of IPv6. So<br /> <br /> 1) Introduce per-port addrs_lock.<br /> <br /> 2) It was needed to fix places where it was forgotten<br /> to take lock (ipvlan_open/ipvlan_close)<br /> <br /> This appears to be a very minor problem though.<br /> Since it&amp;#39;s highly unlikely that ipvlan_add_addr() will<br /> be called on 2 CPU simultaneously. But nevertheless,<br /> this could cause:<br /> <br /> 1) False-negative of ipvlan_addr_busy(): one interface<br /> iterated through all port-&gt;ipvlans + ipvlan-&gt;addrs<br /> under some ipvlan spinlock, and another added IP<br /> under its own lock. Though this is only possible<br /> for IPv6, since looks like only ipvlan_addr6_event() can be<br /> called without rtnl_lock.<br /> <br /> 2) Race since ipvlan_ht_addr_add(port) is called under<br /> different ipvlan-&gt;addrs_lock locks<br /> <br /> This should not affect performance, since add/remove IP<br /> is a rare situation and spinlock is not taken on fast<br /> paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix devlink reload call trace<br /> <br /> Commit 4da71a77fc3b ("ice: read internal temperature sensor") introduced<br /> internal temperature sensor reading via HWMON. ice_hwmon_init() was added<br /> to ice_init_feature() and ice_hwmon_exit() was added to ice_remove(). As a<br /> result if devlink reload is used to reinit the device and then the driver<br /> is removed, a call trace can occur.<br /> <br /> BUG: unable to handle page fault for address: ffffffffc0fd4b5d<br /> Call Trace:<br /> string+0x48/0xe0<br /> vsnprintf+0x1f9/0x650<br /> sprintf+0x62/0x80<br /> name_show+0x1f/0x30<br /> dev_attr_show+0x19/0x60<br /> <br /> The call trace repeats approximately every 10 minutes when system<br /> monitoring tools (e.g., sadc) attempt to read the orphaned hwmon sysfs<br /> attributes that reference freed module memory.<br /> <br /> The sequence is:<br /> 1. Driver load, ice_hwmon_init() gets called from ice_init_feature()<br /> 2. Devlink reload down, flow does not call ice_remove()<br /> 3. Devlink reload up, ice_hwmon_init() gets called from<br /> ice_init_feature() resulting in a second instance<br /> 4. Driver unload, ice_hwmon_exit() called from ice_remove() leaving the<br /> first hwmon instance orphaned with dangling pointer<br /> <br /> Fix this by moving ice_hwmon_exit() from ice_remove() to<br /> ice_deinit_features() to ensure proper cleanup symmetry with<br /> ice_hwmon_init().