Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ipw2200: fix memory leak in ipw_wdev_init()<br /> <br /> In the error path of ipw_wdev_init(), exception value is returned, and<br /> the memory applied for in the function is not released. Also the memory<br /> is not released in ipw_pci_probe(). As a result, memory leakage occurs.<br /> So memory release needs to be added to the error path of ipw_wdev_init().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> seccomp: Move copy_seccomp() to no failure path.<br /> <br /> Our syzbot instance reported memory leaks in do_seccomp() [0], similar<br /> to the report [1]. It shows that we miss freeing struct seccomp_filter<br /> and some objects included in it.<br /> <br /> We can reproduce the issue with the program below [2] which calls one<br /> seccomp() and two clone() syscalls.<br /> <br /> The first clone()d child exits earlier than its parent and sends a<br /> signal to kill it during the second clone(), more precisely before the<br /> fatal_signal_pending() test in copy_process(). When the parent receives<br /> the signal, it has to destroy the embryonic process and return -EINTR to<br /> user space. In the failure path, we have to call seccomp_filter_release()<br /> to decrement the filter&amp;#39;s refcount.<br /> <br /> Initially, we called it in free_task() called from the failure path, but<br /> the commit 3a15fb6ed92c ("seccomp: release filter after task is fully<br /> dead") moved it to release_task() to notify user space as early as possible<br /> that the filter is no longer used.<br /> <br /> To keep the change and current seccomp refcount semantics, let&amp;#39;s move<br /> copy_seccomp() just after the signal check and add a WARN_ON_ONCE() in<br /> free_task() for future debugging.<br /> <br /> [0]:<br /> unreferenced object 0xffff8880063add00 (size 256):<br /> comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.914s)<br /> hex dump (first 32 bytes):<br /> 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................<br /> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br /> backtrace:<br /> do_seccomp (./include/linux/slab.h:600 ./include/linux/slab.h:733 kernel/seccomp.c:666 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991)<br /> do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)<br /> unreferenced object 0xffffc90000035000 (size 4096):<br /> comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.915s)<br /> hex dump (first 32 bytes):<br /> 01 00 00 00 00 00 00 00 00 00 00 00 05 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> __vmalloc_node_range (mm/vmalloc.c:3226)<br /> __vmalloc_node (mm/vmalloc.c:3261 (discriminator 4))<br /> bpf_prog_alloc_no_stats (kernel/bpf/core.c:91)<br /> bpf_prog_alloc (kernel/bpf/core.c:129)<br /> bpf_prog_create_from_user (net/core/filter.c:1414)<br /> do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991)<br /> do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)<br /> unreferenced object 0xffff888003fa1000 (size 1024):<br /> comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.915s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> bpf_prog_alloc_no_stats (./include/linux/slab.h:600 ./include/linux/slab.h:733 kernel/bpf/core.c:95)<br /> bpf_prog_alloc (kernel/bpf/core.c:129)<br /> bpf_prog_create_from_user (net/core/filter.c:1414)<br /> do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991)<br /> do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)<br /> unreferenced object 0xffff888006360240 (size 16):<br /> comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.915s)<br /> hex dump (first 16 bytes):<br /> 01 00 37 00 76 65 72 6c e0 83 01 06 80 88 ff ff ..7.verl........<br /> backtrace:<br /> bpf_prog_store_orig_filter (net/core/filter.c:1137)<br /> bpf_prog_create_from_user (net/core/filter.c:1428)<br /> do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991)<br /> do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)<br /> unreferenced object 0xffff888<br /> ---truncated---

Traefik is an HTTP reverse proxy and load balancer. Versions 3.5.0 through 3.6.2 have inverted TLS verification logic in the nginx.ingress.kubernetes.io/proxy-ssl-verify annotation. Setting the annotation to "on" (intending to enable backend TLS certificate verification) actually disables verification, allowing man-in-the-middle attacks against HTTPS backends when operators believe they are protected. This issue is fixed in version 3.6.3.

Traefik is an HTTP reverse proxy and load balancer. For versions prior to 2.11.32 and 2.11.31 through 3.6.2, requests using PathPrefix, Path or PathRegex matchers can bypass path normalization. When Traefik uses path-based routing, requests containing URL-encoded restricted characters (/, \, Null, ;, ?, #) can bypass the middleware chain and reach unintended backends. For example, a request to http://mydomain.example.com/admin%2F could reach service-a without triggering my-security-middleware, bypassing security controls for the /admin/ path. This issue is fixed in versions 2.11.32 and 3.6.3.

DeepChat is an open-source AI chat platform that supports cloud models and LLMs. Versions 0.5.1 and below are vulnerable to XSS attacks through improperly sanitized Mermaid content. The recent security patch for MermaidArtifact.vue is insufficient and can be bypassed using unquoted HTML attributes combined with HTML entity encoding. Remote Code Execution is possible on the victim&amp;#39;s machine via the electron.ipcRenderer interface, bypassing the regex filter intended to strip dangerous attributes. There is no fix at time of publication.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: zynq: Fix refcount leak in zynq_early_slcr_init<br /> <br /> of_find_compatible_node() returns a node pointer with refcount incremented,<br /> we should use of_node_put() on error path.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> amdgpu: validate offset_in_bo of drm_amdgpu_gem_va<br /> <br /> This is motivated by OOB access in amdgpu_vm_update_range when<br /> offset_in_bo+map_size overflows.<br /> <br /> v2: keep the validations in amdgpu_vm_bo_map<br /> v3: add the validations to amdgpu_vm_bo_map/amdgpu_vm_bo_replace_map<br /> rather than to amdgpu_gem_va_ioctl

NiceGUI is a Python-based UI framework. Versions 3.3.1 and below are subject to a XSS vulnerability through the ui.interactive_image component of NiceGUI. The component renders SVG content using Vue&amp;#39;s v-html directive without any sanitization. This allows attackers to inject malicious HTML or JavaScript via the SVG tag whenever the image component is rendered or updated. This is particularly dangerous for dashboards or multi-user applications displaying user-generated content or annotations. This issue is fixed in version 3.4.0.

A vulnerability was found in code-projects Employee Profile Management System 1.0. Affected is an unknown function of the file edit_personnel.php. The manipulation of the argument per_id results in sql injection. The attack can be launched remotely. The exploit has been made public and could be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: release crypto keyslot before reporting I/O complete<br /> <br /> Once all I/O using a blk_crypto_key has completed, filesystems can call<br /> blk_crypto_evict_key(). However, the block layer currently doesn&amp;#39;t call<br /> blk_crypto_put_keyslot() until the request is being freed, which happens<br /> after upper layers have been told (via bio_endio()) the I/O has<br /> completed. This causes a race condition where blk_crypto_evict_key()<br /> can see &amp;#39;slot_refs != 0&amp;#39; without there being an actual bug.<br /> <br /> This makes __blk_crypto_evict_key() hit the<br /> &amp;#39;WARN_ON_ONCE(atomic_read(&amp;slot-&gt;slot_refs) != 0)&amp;#39; and return without<br /> doing anything, eventually causing a use-after-free in<br /> blk_crypto_reprogram_all_keys(). (This is a very rare bug and has only<br /> been seen when per-file keys are being used with fscrypt.)<br /> <br /> There are two options to fix this: either release the keyslot before<br /> bio_endio() is called on the request&amp;#39;s last bio, or make<br /> __blk_crypto_evict_key() ignore slot_refs. Let&amp;#39;s go with the first<br /> solution, since it preserves the ability to report bugs (via<br /> WARN_ON_ONCE) where a key is evicted while still in-use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Cap MSIX used to online CPUs + 1<br /> <br /> The irdma driver can use a maximum number of msix vectors equal<br /> to num_online_cpus() + 1 and the kernel warning stack below is shown<br /> if that number is exceeded.<br /> <br /> The kernel throws a warning as the driver tries to update the affinity<br /> hint with a CPU mask greater than the max CPU IDs. Fix this by capping<br /> the MSIX vectors to num_online_cpus() + 1.<br /> <br /> WARNING: CPU: 7 PID: 23655 at include/linux/cpumask.h:106 irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma]<br /> RIP: 0010:irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma]<br /> Call Trace:<br /> irdma_rt_init_hw+0xa62/0x1290 [irdma]<br /> ? irdma_alloc_local_mac_entry+0x1a0/0x1a0 [irdma]<br /> ? __is_kernel_percpu_address+0x63/0x310<br /> ? rcu_read_lock_held_common+0xe/0xb0<br /> ? irdma_lan_unregister_qset+0x280/0x280 [irdma]<br /> ? irdma_request_reset+0x80/0x80 [irdma]<br /> ? ice_get_qos_params+0x84/0x390 [ice]<br /> irdma_probe+0xa40/0xfc0 [irdma]<br /> ? rcu_read_lock_bh_held+0xd0/0xd0<br /> ? irdma_remove+0x140/0x140 [irdma]<br /> ? rcu_read_lock_sched_held+0x62/0xe0<br /> ? down_write+0x187/0x3d0<br /> ? auxiliary_match_id+0xf0/0x1a0<br /> ? irdma_remove+0x140/0x140 [irdma]<br /> auxiliary_bus_probe+0xa6/0x100<br /> __driver_probe_device+0x4a4/0xd50<br /> ? __device_attach_driver+0x2c0/0x2c0<br /> driver_probe_device+0x4a/0x110<br /> __driver_attach+0x1aa/0x350<br /> bus_for_each_dev+0x11d/0x1b0<br /> ? subsys_dev_iter_init+0xe0/0xe0<br /> bus_add_driver+0x3b1/0x610<br /> driver_register+0x18e/0x410<br /> ? 0xffffffffc0b88000<br /> irdma_init_module+0x50/0xaa [irdma]<br /> do_one_initcall+0x103/0x5f0<br /> ? perf_trace_initcall_level+0x420/0x420<br /> ? do_init_module+0x4e/0x700<br /> ? __kasan_kmalloc+0x7d/0xa0<br /> ? kmem_cache_alloc_trace+0x188/0x2b0<br /> ? kasan_unpoison+0x21/0x50<br /> do_init_module+0x1d1/0x700<br /> load_module+0x3867/0x5260<br /> ? layout_and_allocate+0x3990/0x3990<br /> ? rcu_read_lock_held_common+0xe/0xb0<br /> ? rcu_read_lock_sched_held+0x62/0xe0<br /> ? rcu_read_lock_bh_held+0xd0/0xd0<br /> ? __vmalloc_node_range+0x46b/0x890<br /> ? lock_release+0x5c8/0xba0<br /> ? alloc_vm_area+0x120/0x120<br /> ? selinux_kernel_module_from_file+0x2a5/0x300<br /> ? __inode_security_revalidate+0xf0/0xf0<br /> ? __do_sys_init_module+0x1db/0x260<br /> __do_sys_init_module+0x1db/0x260<br /> ? load_module+0x5260/0x5260<br /> ? do_syscall_64+0x22/0x450<br /> do_syscall_64+0xa5/0x450<br /> entry_SYSCALL_64_after_hwframe+0x66/0xdb

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: fix decoder disable pm crash<br /> <br /> Can&amp;#39;t call pm_runtime_disable when the architecture support sub device for<br /> &amp;#39;dev-&gt;pm.dev&amp;#39; is NUll, or will get below crash log.<br /> <br /> [ 10.771551] pc : _raw_spin_lock_irq+0x4c/0xa0<br /> [ 10.771556] lr : __pm_runtime_disable+0x30/0x130<br /> [ 10.771558] sp : ffffffc01e4cb800<br /> [ 10.771559] x29: ffffffc01e4cb800 x28: ffffffdf082108a8<br /> [ 10.771563] x27: ffffffc01e4cbd70 x26: ffffff8605df55f0<br /> [ 10.771567] x25: 0000000000000002 x24: 0000000000000002<br /> [ 10.771570] x23: ffffff85c0dc9c00 x22: 0000000000000001<br /> [ 10.771573] x21: 0000000000000001 x20: 0000000000000000<br /> [ 10.771577] x19: 00000000000000f4 x18: ffffffdf2e9fbe18<br /> [ 10.771580] x17: 0000000000000000 x16: ffffffdf2df13c74<br /> [ 10.771583] x15: 00000000000002ea x14: 0000000000000058<br /> [ 10.771587] x13: ffffffdf2de1b62c x12: ffffffdf2e9e30e4<br /> [ 10.771590] x11: 0000000000000000 x10: 0000000000000001<br /> [ 10.771593] x9 : 0000000000000000 x8 : 00000000000000f4<br /> [ 10.771596] x7 : 6bff6264632c6264 x6 : 0000000000008000<br /> [ 10.771600] x5 : 0080000000000000 x4 : 0000000000000001<br /> [ 10.771603] x3 : 0000000000000008 x2 : 0000000000000001<br /> [ 10.771608] x1 : 0000000000000000 x0 : 00000000000000f4<br /> [ 10.771613] Call trace:<br /> [ 10.771617] _raw_spin_lock_irq+0x4c/0xa0<br /> [ 10.771620] __pm_runtime_disable+0x30/0x130<br /> [ 10.771657] mtk_vcodec_probe+0x69c/0x728 [mtk_vcodec_dec 800cc929d6631f79f9b273254c8db94d0d3500dc]<br /> [ 10.771662] platform_drv_probe+0x9c/0xbc<br /> [ 10.771665] really_probe+0x13c/0x3a0<br /> [ 10.771668] driver_probe_device+0x84/0xc0<br /> [ 10.771671] device_driver_attach+0x54/0x78