Vulnerabilities

AIRI is a self-hosted, artificial intelligence based Grok Companion. In v0.7.2-beta.2 in the `packages/stage-ui/src/components/MarkdownRenderer.vue` path, the Markdown content is processed using the useMarkdown composable, and the processed HTML is rendered directly into the DOM using v-html. An attacker creates a card file containing malicious HTML/JavaScript, then simply processes it using the highlightTagToHtml function (which simply replaces template tags without HTML escaping), and then directly renders it using v-html, leading to cross-site scripting (XSS). The project also exposes the Tauri API, which can be called from the frontend. The MCP plugin exposes a command execution interface function in `crates/tauri-plugin-mcp/src/lib.rs`. This allows arbitrary command execution. `connect_server` directly passes the user-supplied `command` and `args` parameters to `Command::new(command).args(args)` without any input validation or whitelisting. Thus, the previous XSS exploit could achieve command execution through this interface. v0.7.2-beta.3 fixes the issue.

An issue was discovered in Subrion CMS 4.2.1, allowing authenticated adminitrators or moderators with access to the built-in Run SQL Query feature under the SQL Tool admin panel - to gain escalated privileges in the context of the SQL query tool.

Flask-AppBuilder is an application development framework. Prior to version 4.8.1, when Flask-AppBuilder is configured to use OAuth, LDAP, or other non-database authentication methods, the password reset endpoint remains registered and accessible, despite not being displayed in the user interface. This allows an enabled user to reset their password and be able to create JWT tokens even after the user is disabled on the authentication provider. Users should upgrade to Flask-AppBuilder version 4.8.1 or later to receive a fix. If immediate upgrade is not possible, manually disable password reset routes in the application configuration; implement additional access controls at the web server or proxy level to block access to the reset my password URL; and/or monitor for suspicious password reset attempts from disabled accounts.

OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.12 and earlier, an unsafe deserialization and validation of printer attributes causes null dereference in the libcups library. This is a remote DoS vulnerability available in local subnet in default configurations. It can cause the cups & cups-browsed to crash, on all the machines in local network who are listening for printers (so by default for all regular linux machines). On systems where the vulnerability CVE-2024-47176 (cups-filters 1.x/cups-browsed 2.x vulnerability) was not fixed, and the firewall on the machine does not reject incoming communication to IPP port, and the machine is set to be available to public internet, attack vector "Network" is possible. The current versions of CUPS and cups-browsed projects have the attack vector "Adjacent" in their default configurations. Version 2.4.13 contains a patch for CVE-2025-58364.

matrix-sdk-base is the base component to build a Matrix client library. In matrix-sdk-base before 0.14.1, calling the `RoomMember::normalized_power_level()` method can cause a panic if a room member has a power level of `Int::Min`. The issue is fixed in matrix-sdk-base 0.14.1. The affected method isn’t used internally, so avoiding calling `RoomMember::normalized_power_level()` prevents the panic.

OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.12 and earlier, when the `AuthType` is set to anything but `Basic`, if the request contains an `Authorization: Basic ...` header, the password is not checked. This results in authentication bypass. Any configuration that allows an `AuthType` that is not `Basic` is affected. Version 2.4.13 fixes the issue.

Insecure Direct Object Reference (IDOR) vulnerability in Liferay Portal 7.4.0 through 7.4.3.124, and Liferay DXP 2024.Q2.0 through 2024.Q2.6, 2024.Q1.1 through 2024.Q1.12 and 7.4 GA through update 92 allows remote authenticated users to from one virtual instance to access, create, edit, relate data/object entries/definitions to an object in a different virtual instance.

Insecure Direct Object Reference (IDOR) vulnerability in Liferay Portal 7.4.0 through 7.4.3.124, and Liferay DXP 2024.Q2.0 through 2024.Q2.7, 2024.Q1.1 through 2024.Q1.12, and 7.4 GA through update 92 allows remote authenticated users to access a workflow definition by name via the API

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: dm-crypt: Do not partially accept write BIOs with zoned targets<br /> <br /> Read and write operations issued to a dm-crypt target may be split<br /> according to the dm-crypt internal limits defined by the max_read_size<br /> and max_write_size module parameters (default is 128 KB). The intent is<br /> to improve processing time of large BIOs by splitting them into smaller<br /> operations that can be parallelized on different CPUs.<br /> <br /> For zoned dm-crypt targets, this BIO splitting is still done but without<br /> the parallel execution to ensure that the issuing order of write<br /> operations to the underlying devices remains sequential. However, the<br /> splitting itself causes other problems:<br /> <br /> 1) Since dm-crypt relies on the block layer zone write plugging to<br /> handle zone append emulation using regular write operations, the<br /> reminder of a split write BIO will always be plugged into the target<br /> zone write plugged. Once the on-going write BIO finishes, this<br /> reminder BIO is unplugged and issued from the zone write plug work.<br /> If this reminder BIO itself needs to be split, the reminder will be<br /> re-issued and plugged again, but that causes a call to a<br /> blk_queue_enter(), which may block if a queue freeze operation was<br /> initiated. This results in a deadlock as DM submission still holds<br /> BIOs that the queue freeze side is waiting for.<br /> <br /> 2) dm-crypt relies on the emulation done by the block layer using<br /> regular write operations for processing zone append operations. This<br /> still requires to properly return the written sector as the BIO<br /> sector of the original BIO. However, this can be done correctly only<br /> and only if there is a single clone BIO used for processing the<br /> original zone append operation issued by the user. If the size of a<br /> zone append operation is larger than dm-crypt max_write_size, then<br /> the orginal BIO will be split and processed as a chain of regular<br /> write operations. Such chaining result in an incorrect written sector<br /> being returned to the zone append issuer using the original BIO<br /> sector. This in turn results in file system data corruptions using<br /> xfs or btrfs.<br /> <br /> Fix this by modifying get_max_request_size() to always return the size<br /> of the BIO to avoid it being split with dm_accpet_partial_bio() in<br /> crypt_map(). get_max_request_size() is renamed to<br /> get_max_request_sectors() to clarify the unit of the value returned<br /> and its interface is changed to take a struct dm_target pointer and a<br /> pointer to the struct bio being processed. In addition to this change,<br /> to ensure that crypt_alloc_buffer() works correctly, set the dm-crypt<br /> device max_hw_sectors limit to be at most<br /> BIO_MAX_VECS

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: x86/aegis - Add missing error checks<br /> <br /> The skcipher_walk functions can allocate memory and can fail, so<br /> checking for errors is necessary.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPE<br /> <br /> On Google gs101, the number of UTP transfer request slots (nutrs) is 32,<br /> and in this case the driver ends up programming the UTRL_NEXUS_TYPE<br /> incorrectly as 0.<br /> <br /> This is because the left hand side of the shift is 1, which is of type<br /> int, i.e. 31 bits wide. Shifting by more than that width results in<br /> undefined behaviour.<br /> <br /> Fix this by switching to the BIT() macro, which applies correct type<br /> casting as required. This ensures the correct value is written to<br /> UTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shift<br /> warning:<br /> <br /> UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21<br /> shift exponent 32 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> <br /> For consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPE<br /> write.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: host: Detect events pointing to unexpected TREs<br /> <br /> When a remote device sends a completion event to the host, it contains a<br /> pointer to the consumed TRE. The host uses this pointer to process all of<br /> the TREs between it and the host&amp;#39;s local copy of the ring&amp;#39;s read pointer.<br /> This works when processing completion for chained transactions, but can<br /> lead to nasty results if the device sends an event for a single-element<br /> transaction with a read pointer that is multiple elements ahead of the<br /> host&amp;#39;s read pointer.<br /> <br /> For instance, if the host accesses an event ring while the device is<br /> updating it, the pointer inside of the event might still point to an old<br /> TRE. If the host uses the channel&amp;#39;s xfer_cb() to directly free the buffer<br /> pointed to by the TRE, the buffer will be double-freed.<br /> <br /> This behavior was observed on an ep that used upstream EP stack without<br /> &amp;#39;commit 6f18d174b73d ("bus: mhi: ep: Update read pointer only after buffer<br /> is written")&amp;#39;. Where the device updated the events ring pointer before<br /> updating the event contents, so it left a window where the host was able to<br /> access the stale data the event pointed to, before the device had the<br /> chance to update them. The usual pattern was that the host received an<br /> event pointing to a TRE that is not immediately after the last processed<br /> one, so it got treated as if it was a chained transaction, processing all<br /> of the TREs in between the two read pointers.<br /> <br /> This commit aims to harden the host by ensuring transactions where the<br /> event points to a TRE that isn&amp;#39;t local_rp + 1 are chained.<br /> <br /> [mani: added stable tag and reworded commit message]