Vulnerabilities

melange allows users to build apk packages using declarative pipelines. Apko prior to version 1.2.9, corresponding to melange prior to version 0.50.4, verified the control section hash (`.PKGINFO` etc.) against the signed `APKINDEX`, but never verified the data section hash (the actual package files that get installed). An attacker who could compromise a mirror, poison a cache, or MITM a package fetch could substitute arbitrary file contents while the control hash check still passed. Apko version 1.2.9 and melange version 0.50.4 contain a fix.

OpenRemote is an open-source internet-of-things platform. Prior to version 1.24.1, the predicted datapoint write endpoint allows users with only `read:assets` privileges to write predicted datapoints. Version 1.24.1 fixes the issue.

Kimai is an open-source time tracking application. Versions prior to 2.58.0 contain a server-side request forgery vulnerability in their invoice PDF preview and generation workflow. If an attacker can control Markdown content that is later rendered into an invoice PDF, such as `Customer.invoiceText`, the server-side PDF renderer will fetch remote image URLs embedded in Markdown image syntax. This allows the application server to issue outbound requests to attacker-controlled or internal targets during PDF rendering. The behavior can be used for internal network probing, server-side reachability checks, and potentially follow-on exploitation depending on deployment environment and accessible internal services. Version 2.58.0 patches the issue.

NL Portal Backend Libraries provide backend components for Dutch government portals that interact with residents, customers, suppliers, and partner organizations. The `nl.nl-portal:taak` package from version 1.5.0 through 3.0.0 fails to verify ownership when processing the `submitTaakV2` GraphQL mutation, allowing an authenticated user who knows or guesses another user’s task ID to read its form data, overwrite its submitted data, and mark the task as completed. Version 3.0.1 contains a patch. As a workaround, block the `submitTaakV2` mutation at the API gateway or restrict the `/graphql` endpoint to trusted networks

Mousehole is a background service to update a seedbox IP for MAM and web app to manage it. Prior to version 0.4.05, Mousehole's HTTP/WebSocket management boundary is reachable without application-layer authentication or browser/LAN provenance checks. The service stores a MyAnonamouse (MAM) session cookie in state and reuses the same cookie-bearing serialization for persisted state, public API responses, and WebSocket state updates. Any client that can reach the published Mousehole port can read cookie-bearing state, connect to WebSocket state updates, replace the stored cookie, or force MAM update side effects. The deployment examples publish port 5010 broadly with Docker's `5010:5010` syntax, which can make the issue reachable on mixed-trust LAN/VPN interfaces. Version 0.4.0 patches the issue.

ArduinoCore-avr contains the source code and configuration files of the Arduino AVR Boards platform. A vulnerability in versions prior to 1.8.8 allows an attacker to trigger a stack-based buffer overflow when concatenating floating-point values of sufficiently large magnitude onto an Arduino String object. By passing values near the extremes of the float or double range to `String::concat(float)`, `String::concat(double)`, `String::operator+=()`, or the `+` operator with a float/double operand, `dtostrf()` writes beyond the fixed-size stack buffer, causing memory corruption and denial of service. Under specific conditions, this could enable arbitrary code execution on AVR-based Arduino boards. The fix is included starting from the `1.8.8 `release.

ArduinoBLE enables Bluetooth Low Energy connectivity on certain Arduino models. Versions prior to 2.0.2 contain a missing bounds check in the ATT layer write request handler that allows a remote, unauthenticated BLE client to corrupt memory in the ATTClass global object. Devices running ArduinoBLE with one or more characteristics configured with the BLEEncryption property are affected. The fix is included starting from the 2.0.2 release.

matrix-sdk-ui provides GUI-centric utilities on top of matrix-rust-sdk. The message edit validation logic in the `matrix-sdk-ui` crate prior to 0.17.0 is missing a check: when replacing an encrypted event, the replacement event itself is not required to be encrypted. This enables a malicious homeserver administrators (or actors with equivalent power) to impersonate or spoof messages as if they were sent by a victim user. `matrix-sdk-ui` 0.17.0 fixes the message edit validation logic to align with the algorithm for replacement events[^1] described in the Matrix specification. No known workarounds are available.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KEYS: trusted: Fix TPM teardown ordering<br /> <br /> trusted_tpm_exit() drops the TPM chip reference and frees the digest<br /> array before unregistering the trusted key type. key_type_lookup()<br /> holds key_types_sem for reading until the key operation finishes, while<br /> unregister_key_type() takes it for writing. It therefore provides the<br /> synchronization point that must precede backend teardown.<br /> <br /> The current order permits this interleaving:<br /> <br /> CPU 0 CPU 1<br /> trusted_tpm_exit() key_type_lookup("trusted")<br /> put_device(&amp;chip-&gt;dev) trusted_tpm_seal()<br /> kfree(digests) pcrlock()<br /> unregister_key_type() tpm_pcr_extend(..., digests)<br /> <br /> CPU 1 can consequently dereference the freed digest array. The chip can<br /> also be released before callbacks stop using it.<br /> <br /> KASAN reported:<br /> <br /> BUG: KASAN: slab-use-after-free in tpm_pcr_extend+0x1f0/0x200<br /> Read of size 2 at addr ffff88810872d000 by task poc/89<br /> Call Trace:<br /> tpm_pcr_extend+0x1f0/0x200<br /> pcrlock+0x42/0x70 [trusted]<br /> trusted_tpm_seal+0x1b6/0x570 [trusted]<br /> trusted_instantiate+0x293/0x340 [trusted]<br /> __key_instantiate_and_link+0xb2/0x2b0<br /> __key_create_or_update+0x61e/0xb50<br /> __do_sys_add_key+0x1b8/0x310<br /> Allocated by task 88:<br /> __kmalloc_noprof+0x1a7/0x490<br /> do_one_initcall+0xa1/0x390<br /> do_init_module+0x2df/0x840<br /> Freed by task 90:<br /> kfree+0x131/0x3c0<br /> trusted_tpm_exit+0x59/0xa0 [trusted]<br /> __do_sys_delete_module+0x346/0x510<br /> <br /> Move unregister_key_type() before releasing either resource. This stops<br /> new lookups and waits for in-flight key operations to finish before the<br /> backend state is destroyed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pidfd: hold exec_update_lock around namespace ioctl<br /> <br /> The PIDFD_GET_*_NAMESPACE ioctls in pidfd_ioctl() perform a filesystem<br /> credentials ptrace access check before handing out a namespace file<br /> descriptor. The accompanying comment states that the code "mirrors nsfs<br /> behavior", but, unlike the corresponding procfs paths, it does so without<br /> holding the target task&amp;#39;s exec_update_lock.<br /> <br /> proc_ns_get_link() and proc_ns_readlink() both take exec_update_lock for<br /> reading around the ptrace check and the namespace lookup, so that the<br /> credentials used for the access decision match those of the task when its<br /> namespace is read. Without it, a caller can pass the check against the<br /> target&amp;#39;s old credentials and then read the namespace after the target has<br /> execve()&amp;#39;d a setuid binary and committed new credentials -- accessing<br /> namespace information it should have been denied.<br /> <br /> Hold exec_update_lock for reading around the ptrace check and the<br /> namespace lookup so that pidfd truly mirrors nsfs behavior, as the comment<br /> already claims. open_namespace() itself runs outside the lock: once a<br /> namespace reference is obtained it carries its own refcount and is opened<br /> with the caller&amp;#39;s own credentials, so a concurrent execve() on the target<br /> can no longer affect the outcome.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/migrate_device: clear stale mapping after freeing swapcache<br /> <br /> __migrate_device_pages() reads the folio mapping before calling<br /> folio_free_swap(). When folio_free_swap() succeeds, the folio is removed<br /> from the swap cache, but the saved mapping still points to swap_space.<br /> <br /> Passing the stale mapping to folio_migrate_mapping() makes it use the<br /> mapped-folio path for a folio that is no longer in swapcache. It can then<br /> operate on swap_space.i_pages with invalid reference accounting,<br /> eventually triggering a folio reference count BUG.<br /> <br /> After a successful split, nr still contains the number of pages in the<br /> original large folio, although each resulting page is now a separate<br /> order-0 folio. Reset nr to 1 so each split folio is processed separately,<br /> including its own swapcache removal and mapping lookup.<br /> <br /> Refresh the saved mapping after folio_free_swap() so the current folio<br /> state is used during migration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: gadget: Fix use-after-free in dwc3_gadget_free_endpoints due to race condition<br /> <br /> In dwc3_gadget_init_endpoint, &amp;dep-&gt;nostream_work is bound with<br /> dwc3_nostream_work, and dwc3_gadget_endpoint_stream_event can queue<br /> this delayed work on system_percpu_wq when a DEPEVT_STREAM_NOSTREAM<br /> event is received.<br /> <br /> If we remove the gadget, dwc3_gadget_free_endpoints makes cleanup and<br /> the memory allocated for dep with kzalloc() is released by kfree(dep),<br /> while the delayed work mentioned above may still be pending or<br /> running. The sequence of operations that may lead to a UAF bug is as<br /> follows:<br /> <br /> CPU0 CPU1<br /> <br /> | dwc3_thread_interrupt<br /> | dwc3_endpoint_interrupt<br /> | dwc3_gadget_endpoint_stream_event<br /> | queue_delayed_work(system_percpu_wq,<br /> | &amp;dep-&gt;nostream_work)<br /> dwc3_gadget_free_endpoints |<br /> dwc3_free_trb_pool(dep) |<br /> list_del(&amp;dep-&gt;endpoint.ep_list) |<br /> dwc3_debugfs_remove_endpoint_dir(dep) |<br /> kfree(dep) |<br /> // dep is freed |<br /> | dwc3_nostream_work<br /> | // use dep (use-after-free)<br /> <br /> Fix it by canceling the delayed work before kfree(dep) in<br /> dwc3_gadget_free_endpoints.