CWE-755 vulnerabilities

SvelteKit is a framework for rapidly developing robust, performant web applications using Svelte. Prior to 2.57.1, redirect, when called from inside the handle server hook with a location parameter containing characters that are invalid in a HTTP header, will cause an unhandled TypeError. This could result in DoS on some platforms, especially if the location passed to redirect contains unsanitized user input. This vulnerability is fixed in 2.57.1.

psd-tools is a Python package for working with Adobe Photoshop PSD files. Prior to version 1.12.2, when a PSD file contains malformed RLE-compressed image data (e.g. a literal run that extends past the expected row size), decode_rle() raises ValueError which propagated all the way to the user, crashing psd.composite() and psd-tools export. decompress() already had a fallback that replaces failed channels with black pixels when result is None, but it never triggered because the ValueError from decode_rle() was not caught. The fix in version 1.12.2 wraps the decode_rle() call in a try/except so the existing fallback handles the error gracefully.

Wasmtime is a runtime for WebAssembly. Starting with Wasmtime 39.0.0, the `component-model-async` feature became the default, which brought with it a new implementation of `[Typed]Func::call_async` which made it capable of calling async-typed guest export functions. However, that implementation had a bug leading to a panic under certain circumstances: First, the host embedding calls `[Typed]Func::call_async` on a function exported by a component, polling the returned `Future` once. Second, the component function yields control to the async runtime (e.g. Tokio), e.g. due to a call to host function registered using `LinkerInstance::func_wrap_async` which yields, or due an epoch interruption. Third, the host embedding drops the `Future` after polling it once. This leaves the component instance in a non-reenterable state since the call never had a chance to complete. Fourth, the host embedding calls `[Typed]Func::call_async` again, polling the returned `Future`. Since the component instance cannot be entered at this point, the call traps, but not before allocating a task and thread for the call. Fifth, the host embedding ignores the trap and drops the `Future`. This panics due to the runtime attempting to dispose of the task created above, which panics since the thread has not yet exited. When a host embedder using the affected versions of Wasmtime calls `wasmtime::component::[Typed]Func::call_async` on a guest export and then drops the returned future without waiting for it to resolve, and then does so again with the same component instance, Wasmtime will panic. Embeddings that have the `component-model-async` compile-time feature disabled are unaffected. Wasmtime 40.0.4 and 41.0.4 have been patched to fix this issue. Versions 42.0.0 and later are not affected. If an embedding is not actually using any component-model-async features then disabling the `component-model-async` Cargo feature can work around this issue. This issue can also be worked around by either ensuring every `call_async` future is awaited until it completes or refraining from using the `Store` again after dropping a not-yet-resolved `call_async` future.

Cube is a semantic layer for building data applications. From 1.1.17 to before 1.5.13 and 1.4.2, it is possible to make the entire Cube API unavailable by submitting a specially crafted request to a Cube API endpoint. This vulnerability is fixed in 1.5.13 and 1.4.2.

VB-Audio Voicemeeter, Voicemeeter Banana, and Voicemeeter Potato (versions ending in 1.1.1.9, 2.1.1.9, and 3.1.1.9 and earlier, respectively), as well as VB-Audio Matrix and Matrix Coconut (versions ending in 1.0.2.2 and 2.0.2.2 and earlier, respectively), contain a vulnerability in their virtual audio drivers (vbvoicemeetervaio64*.sys, vbmatrixvaio64*.sys, vbaudio_vmauxvaio*.sys, vbaudio_vmvaio*.sys, and vbaudio_vmvaio3*.sys). The drivers map non-paged pool memory into user space via MmMapLockedPagesSpecifyCache using UserMode access without proper exception handling. If the mapping fails, such as when a process has exhausted available virtual address space, MmMapLockedPagesSpecifyCache raises an exception that is not caught, causing a kernel crash (BSoD), typically SYSTEM_SERVICE_EXCEPTION with STATUS_NO_MEMORY. This flaw allows a local unprivileged user to trigger a denial-of-service on affected Windows systems.

RustFS is a distributed object storage system built in Rust. In versions 1.0.0-alpha.13 to 1.0.0-alpha.77, a malformed gRPC GetMetrics request causes get_metrics to unwrap() failed deserialization of metric_type/opts, panicking the handler thread and enabling remote denial of service of the metrics endpoint. This issue has been patched in version 1.0.0-alpha.78.

In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.

In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.

In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.

In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; }; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.

Tuleap is a tool for end to end traceability of application and system developments. Prior to Tuleap Community Edition 15.13.99.113, Tuleap Enterprise Edition 15.13-5, and Tuleap Enterprise Edition 15.12-5, users might see tracker names they should not have access to. Tuleap Community Edition 15.13.99.113, Tuleap Enterprise Edition 15.13-5, and Tuleap Enterprise Edition 15.12-8 fix this issue.

Tuleap is a tool for end to end traceability of application and system developments. Prior to Tuleap Community Edition 15.13.99.110, Tuleap Enterprise Edition 15.13-5, and Tuleap Enterprise Edition 15.12-5, administrators of a project can access the content of trackers with permissions restrictions of project they are members of but not admin via the cross tracker search widget. Tuleap Community Edition 15.13.99.110, Tuleap Enterprise Edition 15.13-5, and Tuleap Enterprise Edition 15.12-8 fix this issue.

Tuleap is a tool for end to end traceability of application and system developments. Prior to Tuleap Community Edition 15.13.99.40, Tuleap Enterprise Edition 15.13-3, and Tuleap Enterprise Edition 15.12-6, users might receive email notification with information they should not have access to. Tuleap Community Edition 15.13.99.40, Tuleap Enterprise Edition 15.13-3, and Tuleap Enterprise Edition 15.12-6 fix this issue.

Improper handling of exceptional conditions in Setupwizard prior to SMR Aug-2024 Release 1 allows physical attackers to bypass proper validation.