Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Fix memory leak in vmw_mksstat_add_ioctl()<br /> <br /> If the copy of the description string from userspace fails, then the page<br /> for the instance descriptor doesn&amp;#39;t get freed before returning -EFAULT,<br /> which leads to a memleak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix deadlock due to mbcache entry corruption<br /> <br /> When manipulating xattr blocks, we can deadlock infinitely looping<br /> inside ext4_xattr_block_set() where we constantly keep finding xattr<br /> block for reuse in mbcache but we are unable to reuse it because its<br /> reference count is too big. This happens because cache entry for the<br /> xattr block is marked as reusable (e_reusable set) although its<br /> reference count is too big. When this inconsistency happens, this<br /> inconsistent state is kept indefinitely and so ext4_xattr_block_set()<br /> keeps retrying indefinitely.<br /> <br /> The inconsistent state is caused by non-atomic update of e_reusable bit.<br /> e_reusable is part of a bitfield and e_reusable update can race with<br /> update of e_referenced bit in the same bitfield resulting in loss of one<br /> of the updates. Fix the problem by using atomic bitops instead.<br /> <br /> This bug has been around for many years, but it became *much* easier<br /> to hit after commit 65f8b80053a1 ("ext4: fix race when reusing xattr<br /> blocks").

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: ocxl: fix possible name leak in ocxl_file_register_afu()<br /> <br /> If device_register() returns error in ocxl_file_register_afu(),<br /> the name allocated by dev_set_name() need be freed. As comment<br /> of device_register() says, it should use put_device() to give<br /> up the reference in the error path. So fix this by calling<br /> put_device(), then the name can be freed in kobject_cleanup(),<br /> and info is freed in info_release().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: mm: add missing memcpy in kasan_init<br /> <br /> Hi Atish,<br /> <br /> It seems that the panic is due to the missing memcpy during kasan_init.<br /> Could you please check whether this patch is helpful?<br /> <br /> When doing kasan_populate, the new allocated base_pud/base_p4d should<br /> contain kasan_early_shadow_{pud, p4d}&amp;#39;s content. Add the missing memcpy<br /> to avoid page fault when read/write kasan shadow region.<br /> <br /> Tested on:<br /> - qemu with sv57 and CONFIG_KASAN on.<br /> - qemu with sv48 and CONFIG_KASAN on.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: qcom: fix memory leak in error path<br /> <br /> If for some reason the speedbin length is incorrect, then there is a<br /> memory leak in the error path because we never free the speedbin buffer.<br /> This commit fixes the error path to always free the speedbin buffer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwrng: geode - Fix PCI device refcount leak<br /> <br /> for_each_pci_dev() is implemented by pci_get_device(). The comment of<br /> pci_get_device() says that it will increase the reference count for the<br /> returned pci_dev and also decrease the reference count for the input<br /> pci_dev @from if it is not NULL.<br /> <br /> If we break for_each_pci_dev() loop with pdev not NULL, we need to call<br /> pci_dev_put() to decrease the reference count. We add a new struct<br /> &amp;#39;amd_geode_priv&amp;#39; to record pointer of the pci_dev and membase, and then<br /> add missing pci_dev_put() for the normal and error path.

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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---

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.