Vulnerabilities

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.

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.

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.

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.

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.

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.

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.

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().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag<br /> <br /> This is more of a preventive patch to make the code more consistent and<br /> to prevent possible exploits that employ child qlen manipulations on qfq.<br /> use cl_is_active instead of relying on the child qdisc&amp;#39;s qlen to determine<br /> class activation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> timekeeping: Adjust the leap state for the correct auxiliary timekeeper<br /> <br /> When __do_ajdtimex() was introduced to handle adjtimex for any<br /> timekeeper, this reference to tk_core was not updated. When called on an<br /> auxiliary timekeeper, the core timekeeper would be updated incorrectly.<br /> <br /> This gets caught by the lock debugging diagnostics because the<br /> timekeepers sequence lock gets written to without holding its<br /> associated spinlock:<br /> <br /> WARNING: include/linux/seqlock.h:226 at __do_adjtimex+0x394/0x3b0, CPU#2: test/125<br /> aux_clock_adj (kernel/time/timekeeping.c:2979)<br /> __do_sys_clock_adjtime (kernel/time/posix-timers.c:1161 kernel/time/posix-timers.c:1173)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)<br /> <br /> Update the correct auxiliary timekeeper.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/fpsimd: signal: Allocate SSVE storage when restoring ZA<br /> <br /> The code to restore a ZA context doesn&amp;#39;t attempt to allocate the task&amp;#39;s<br /> sve_state before setting TIF_SME. Consequently, restoring a ZA context<br /> can place a task into an invalid state where TIF_SME is set but the<br /> task&amp;#39;s sve_state is NULL.<br /> <br /> In legitimate but uncommon cases where the ZA signal context was NOT<br /> created by the kernel in the context of the same task (e.g. if the task<br /> is saved/restored with something like CRIU), we have no guarantee that<br /> sve_state had been allocated previously. In these cases, userspace can<br /> enter streaming mode without trapping while sve_state is NULL, causing a<br /> later NULL pointer dereference when the kernel attempts to store the<br /> register state:<br /> <br /> | # ./sigreturn-za<br /> | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> | Mem abort info:<br /> | ESR = 0x0000000096000046<br /> | EC = 0x25: DABT (current EL), IL = 32 bits<br /> | SET = 0, FnV = 0<br /> | EA = 0, S1PTW = 0<br /> | FSC = 0x06: level 2 translation fault<br /> | Data abort info:<br /> | ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000<br /> | CM = 0, WnR = 1, TnD = 0, TagAccess = 0<br /> | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> | user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00<br /> | [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000<br /> | Internal error: Oops: 0000000096000046 [#1] SMP<br /> | Modules linked in:<br /> | CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT<br /> | Hardware name: linux,dummy-virt (DT)<br /> | pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> | pc : sve_save_state+0x4/0xf0<br /> | lr : fpsimd_save_user_state+0xb0/0x1c0<br /> | sp : ffff80008070bcc0<br /> | x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658<br /> | x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000<br /> | x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40<br /> | x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000<br /> | x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c<br /> | x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020<br /> | x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0<br /> | x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48<br /> | x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000<br /> | x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440<br /> | Call trace:<br /> | sve_save_state+0x4/0xf0 (P)<br /> | fpsimd_thread_switch+0x48/0x198<br /> | __switch_to+0x20/0x1c0<br /> | __schedule+0x36c/0xce0<br /> | schedule+0x34/0x11c<br /> | exit_to_user_mode_loop+0x124/0x188<br /> | el0_interrupt+0xc8/0xd8<br /> | __el0_irq_handler_common+0x18/0x24<br /> | el0t_64_irq_handler+0x10/0x1c<br /> | el0t_64_irq+0x198/0x19c<br /> | Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800)<br /> | ---[ end trace 0000000000000000 ]---<br /> <br /> Fix this by having restore_za_context() ensure that the task&amp;#39;s sve_state<br /> is allocated, matching what we do when taking an SME trap. Any live<br /> SVE/SSVE state (which is restored earlier from a separate signal<br /> context) must be preserved, and hence this is not zeroed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak<br /> <br /> Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:<br /> gs_usb_receive_bulk_callback(): fix URB memory leak").<br /> <br /> In usb_8dev_open() -&gt; usb_8dev_start(), the URBs for USB-in transfers are<br /> allocated, added to the priv-&gt;rx_submitted anchor and submitted. In the<br /> complete callback usb_8dev_read_bulk_callback(), the URBs are processed and<br /> resubmitted. In usb_8dev_close() -&gt; unlink_all_urbs() the URBs are freed by<br /> calling usb_kill_anchored_urbs(&amp;priv-&gt;rx_submitted).<br /> <br /> However, this does not take into account that the USB framework unanchors<br /> the URB before the complete function is called. This means that once an<br /> in-URB has been completed, it is no longer anchored and is ultimately not<br /> released in usb_kill_anchored_urbs().<br /> <br /> Fix the memory leak by anchoring the URB in the<br /> usb_8dev_read_bulk_callback() to the priv-&gt;rx_submitted anchor.