Vulnerabilities

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's machine via the electron.ipcRenderer interface, bypassing the regex filter intended to strip dangerous attributes. There is no fix at time of publication.

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.

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.

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

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.

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.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix rbtree traversal bug in ext4_mb_use_preallocated<br /> <br /> During allocations, while looking for preallocations(PA) in the per<br /> inode rbtree, we can&amp;#39;t do a direct traversal of the tree because<br /> ext4_mb_discard_group_preallocation() can paralelly mark the pa deleted<br /> and that can cause direct traversal to skip some entries. This was<br /> leading to a BUG_ON() being hit [1] when we missed a PA that could satisfy<br /> our request and ultimately tried to create a new PA that would overlap<br /> with the missed one.<br /> <br /> To makes sure we handle that case while still keeping the performance of<br /> the rbtree, we make use of the fact that the only pa that could possibly<br /> overlap the original goal start is the one that satisfies the below<br /> conditions:<br /> <br /> 1. It must have it&amp;#39;s logical start immediately to the left of<br /> (ie less than) original logical start.<br /> <br /> 2. It must not be deleted<br /> <br /> To find this pa we use the following traversal method:<br /> <br /> 1. Descend into the rbtree normally to find the immediate neighboring<br /> PA. Here we keep descending irrespective of if the PA is deleted or if<br /> it overlaps with our request etc. The goal is to find an immediately<br /> adjacent PA.<br /> <br /> 2. If the found PA is on right of original goal, use rb_prev() to find<br /> the left adjacent PA.<br /> <br /> 3. Check if this PA is deleted and keep moving left with rb_prev() until<br /> a non deleted PA is found.<br /> <br /> 4. This is the PA we are looking for. Now we can check if it can satisfy<br /> the original request and proceed accordingly.<br /> <br /> This approach also takes care of having deleted PAs in the tree.<br /> <br /> (While we are at it, also fix a possible overflow bug in calculating the<br /> end of a PA)<br /> <br /> [1] https://lore.kernel.org/linux-ext4/CA+G9fYv2FRpLqBZf34ZinR8bU2_ZRAUOjKAD3+tKRFaEQHtt8Q@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix dropping valid root bus resources with .end = zero<br /> <br /> On r8a7791/koelsch:<br /> <br /> kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> # cat /sys/kernel/debug/kmemleak<br /> unreferenced object 0xc3a34e00 (size 64):<br /> comm "swapper/0", pid 1, jiffies 4294937460 (age 199.080s)<br /> hex dump (first 32 bytes):<br /> b4 5d 81 f0 b4 5d 81 f0 c0 b0 a2 c3 00 00 00 00 .]...]..........<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmalloc+0xf0/0x140<br /> [] resource_list_create_entry+0x18/0x38<br /> [] pci_add_resource_offset+0x20/0x68<br /> [] devm_of_pci_get_host_bridge_resources.constprop.0+0xb0/0x390<br /> <br /> When coalescing two resources for a contiguous aperture, the second<br /> resource is enlarged to cover the full contiguous range, while the first<br /> resource is marked invalid. This invalidation is done by clearing the<br /> flags, start, and end members.<br /> <br /> When adding the initial resources to the bus later, invalid resources are<br /> skipped. Unfortunately, the check for an invalid resource considers only<br /> the end member, causing false positives.<br /> <br /> E.g. on r8a7791/koelsch, root bus resource 0 ("bus 00") is skipped, and no<br /> longer registered with pci_bus_insert_busn_res() (causing the memory leak),<br /> nor printed:<br /> <br /> pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:<br /> pci-rcar-gen2 ee090000.pci: MEM 0x00ee080000..0x00ee08ffff -&gt; 0x00ee080000<br /> pci-rcar-gen2 ee090000.pci: PCI: revision 11<br /> pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00<br /> -pci_bus 0000:00: root bus resource [bus 00]<br /> pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]<br /> <br /> Fix this by only skipping resources where all of the flags, start, and end<br /> members are zero.