Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl-&gt;lock<br /> <br /> During the SSR/PDR down notification the tx_lock is taken with the<br /> intent to provide synchronization with active DMA transfers.<br /> <br /> But during this period qcom_slim_ngd_down() is invoked, which ends up in<br /> slim_report_absent(), which takes the slim_controller lock. In multiple<br /> other codepaths these two locks are taken in the opposite order (i.e.<br /> slim_controller then tx_lock).<br /> <br /> The result is a lockdep splat, and a possible deadlock:<br /> <br /> rprocctl/449 is trying to acquire lock:<br /> ffff00009793e620 (&amp;ctrl-&gt;lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus<br /> <br /> but task is already holding lock:<br /> ffff00009793fb50 (&amp;ctrl-&gt;tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl<br /> <br /> which lock already depends on the new lock.<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;ctrl-&gt;tx_lock);<br /> lock(&amp;ctrl-&gt;lock);<br /> lock(&amp;ctrl-&gt;tx_lock);<br /> lock(&amp;ctrl-&gt;lock);<br /> <br /> The assumption is that the comment refers to the desire to not call<br /> qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction.<br /> But any such transaction is initiated and completed within a single<br /> qcom_slim_ngd_xfer_msg().<br /> <br /> Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn<br /> down, all child devices are notified that the slimbus is gone and the<br /> child devices are removed.<br /> <br /> Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the<br /> deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> debugobjects: Don&amp;#39;t call fill_pool() in early boot hardirq context<br /> <br /> When booting a debug PREEMPT_RT kernel on an ARM64 system, a "inconsistent<br /> {HARDIRQ-ON-W} -&gt; {IN-HARDIRQ-W} usage" lockdep warning message was<br /> reported to the console.<br /> <br /> During early boot, interrupts are enabled before the scheduler is<br /> enabled. In this window (before SYSTEM_SCHEDULING is set) interrupts can<br /> fire and in the hard interrupt context handler attempt to fill the pool<br /> <br /> This can lead to a deadlock when the interrupt occurred when the interrupt<br /> hits a region which holds a lock that is required to be taken in the<br /> allocation path.<br /> <br /> Add a new can_fill_pool() helper and reorder the exception rule and forbid<br /> this scenario by excluding allocations from hard interrupt context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> debugobjects: Do not fill_pool() if pi_blocked_on<br /> <br /> On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which<br /> asserts if current::pi_blocked_on is set, because a task can obviously only<br /> block on one lock as otherwise the priority inheritenace chain gets<br /> corrupted.<br /> <br /> Prevent this by expanding the conditional to take current::pi_blocked_on<br /> into account.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Use krealloc_array() in dal_vector_reserve()<br /> <br /> [Why &amp; How]<br /> dal_vector_reserve() computes the allocation size as<br /> "capacity * vector-&gt;struct_size" using uint32_t arithmetic, which can<br /> silently wrap to a small value on overflow. This would cause krealloc to<br /> return a smaller buffer than expected, leading to heap overflows on<br /> subsequent vector appends.<br /> <br /> Replace krealloc() with krealloc_array() which performs an internal<br /> overflow check and returns NULL on wrap, preventing the issue.<br /> <br /> (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix out-of-bounds read in dp_get_eq_aux_rd_interval()<br /> <br /> [Why &amp; How]<br /> The aux_rd_interval array in struct dc_lttpr_caps is declared with<br /> MAX_REPEATER_CNT - 1 (7) elements, indexed 0..6. However, the offset<br /> parameter passed to dp_get_eq_aux_rd_interval() can be as large as<br /> MAX_REPEATER_CNT (8) when a sink reports 8 LTTPR repeaters via DPCD.<br /> This leads to an out-of-bounds read of aux_rd_interval[7] when offset<br /> is 8.<br /> <br /> Fix this by growing aux_rd_interval to MAX_REPEATER_CNT elements to<br /> accommodate the full range of valid repeater counts defined by the DP<br /> spec.<br /> <br /> (cherry picked from commit a55a458a8df37a65ffda5cf721d554a8f74f6b04)

The payment integration pretix-oppwa provides support <br /> for the payment providers VR Payment, Hobex, and potentially others <br /> based on Oppwa&amp;#39;s technology. The integration of Oppwa, following their <br /> official documentation, includes a step where the user is redirected <br /> from the payment provider back to our system with a query parameter like<br /> ?resourcePath=/v1/checkouts/{checkoutId}/payment in the URL. Our system is then supposed to fetch the status of the transaction from the URL given by baseUrl + resourcePath.<br /> <br /> <br /> <br /> Our plugin pretix-oppwa did so insecurely by <br /> concatenating the parameter form the URL to the base domain of the API <br /> without further validation and, critically, without a / at the end of the baseUrl. Therefore, an attacker could inject a resourcePath argument in a way that causes pretix to call a different<br /> server instead. Since the request includes the access token (API key) <br /> of the Oppwa account, this would leak the access token, giving access to<br /> data contained in the payment provider&amp;#39;s system. This is fixed with the<br /> release today by strictly validating the given API URL.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> After installing the update, we recommend asking your payment provider for a new access token and updating it in pretix.

A vulnerability in allegroai/clearml versions up to and including 1.16.5 allows for relative path traversal when extracting `.zip` archives using the `ZipFile.extractall()` method in `StorageManager._extract_to_cache()`. This issue arises due to the lack of path traversal validation, enabling an attacker to write arbitrary files to the filesystem. Attack vectors include dataset downloads, artifact downloads, model downloads, and offline session imports. The vulnerability can lead to remote code execution through methods such as cron job injection, SSH key overwrite, or web shell deployment. The issue is resolved in version 2.1.6.

A Race Condition vulnerability affecting BIOVIA Workbook from Release 2021 through Release 2026 could allow a user to access unauthorized data from another user.

MCO does not correctly validate types of uploaded files. File upload validation functionality relies only on client-side checks, which can be bypassed. An authorized, low-privileged attacker can upload files with arbitrary types to the server.<br /> <br /> Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1 but may also affect other versions.

MCO is vulnerable to an Insecure Direct Object Reference (IDOR) vulnerability in the /customer/servlet/mco/webapi/trading-document/fetchPdfStatement endpoint. The application does not properly validate whether an authenticated user is authorized to access a requested document, allowing direct retrieval based on a user-supplied identifier.<br /> An attacker can access trading documents belonging to other users by providing a valid document ID. Although exploitation requires guessing the identifier, predictable ID patterns enable feasible enumeration, leading to unauthorized disclosure of sensitive information.<br /> <br /> Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1 but may also affect other versions.

MCO does not properly enforce authorization checks in the /customer/servlet/mco/webapi/profile-sections/group-membership endpoint. An authenticated user can modify their group membership without proper authorization checks, allowing privilege escalation.<br /> An attacker can add themselves to arbitrary groups by supplying a valid group ID, which can be obtained via other application functionalities (e.g. /customer/servlet/mco/webapi/group/picker/groups), provided he has necessary permissions, or potentially inferred through brute-force techniques.<br /> <br /> <br /> <br /> Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1 but may also affect other versions.

MCO is vulnerable to User Enumeration through authentication-related functionalities. The application returns distinguishable responses for valid and invalid users during username reminder and password reset operations. An attacker can leverage these differences to enumerate valid usernames and email addresses.<br /> <br /> Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1 but may also affect other versions.