Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 9p: fix access mode flags being ORed instead of replaced<br /> <br /> Since commit 1f3e4142c0eb ("9p: convert to the new mount API"),<br /> v9fs_apply_options() applies parsed mount flags with |= onto flags<br /> already set by v9fs_session_init(). For 9P2000.L, session_init sets<br /> V9FS_ACCESS_CLIENT as the default, so when the user mounts with<br /> "access=user", both bits end up set. Access mode checks compare<br /> against exact values, so having both bits set matches neither mode.<br /> <br /> This causes v9fs_fid_lookup() to fall through to the default switch<br /> case, using INVALID_UID (nobody/65534) instead of current_fsuid()<br /> for all fid lookups. Root is then unable to chown or perform other<br /> privileged operations.<br /> <br /> Fix by clearing the access mask before applying the user&amp;#39;s choice.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rockchip: rkcif: fix off by one bugs<br /> <br /> Change these comparisons from &gt; vs &gt;= to avoid accessing one element<br /> beyond the end of the arrays.<br /> While at it, use ARRAY_SIZE instead of the _MAX enum values.<br /> <br /> [fix cosmetic issues]

Improper neutralization of special elements used in an SQL command (&amp;#39;SQL injection&amp;#39;) vulnerability in Netcad Software Inc. E-İmar allows SQL Injection.<br /> <br /> This issue affects E-İmar: from 2.10.1.0 before 3.0.2.

Logseq exposes an IPC handler that allows the renderer process to execute shell commands. While an allowlist restricts the command name (e.g. `git`, `pandoc`, `grep`), the argument string is concatenated with the command and passed to `child_process.spawn` with the `shell: true` option, allowing shell metacharacters in the arguments to bypass the allowlist. An attacker with JavaScript execution in the renderer (e.g. via XSS or a malicious plugin) can execute arbitrary shell commands with the privileges of the Logseq process, leading to remote code execution on the host.<br /> While only version v0.10.15 was tested and confirmed as vulnerable, status of other versions is unknown since this issue was not addressed by a patch.

Uncontrolled Resource Consumption vulnerability in the Elixir standard library&amp;#39;s Version module allows an attacker who controls a version string to cause a denial of service through CPU and memory exhaustion.<br /> <br /> The version parser converts numeric version components (major, minor, patch and numeric pre-release/build identifiers) to integers without bounding their length. A single large all-digit component therefore forces a super-linear, non-yielding base-10 to arbitrary-precision integer conversion (String.to_integer/1, i.e. :erlang.binary_to_integer/1) that pins a BEAM scheduler, and a larger component raises an uncaught SystemLimitError that crashes the calling process. A single moderately sized string (around one megabyte) is enough; no authentication is required.<br /> <br /> This is reachable from the public entry points Version.parse/1, Version.parse!/1, Version.match?/3, Version.compare/2, and Version.parse_requirement/1, which applications routinely call on untrusted input such as HTTP parameters, dependency-manifest fields, and package metadata.<br /> <br /> This vulnerability is associated with program files lib/version.ex and program routines &amp;#39;Elixir.Version.Parser&amp;#39;:parse_digits/2.<br /> <br /> This issue affects Elixir: from 1.5.0 before 1.20.1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: fix nvkm_device leak on aperture removal failure<br /> <br /> When aperture_remove_conflicting_pci_devices() fails during probe, the<br /> error path returns directly without unwinding the nvkm_device that was<br /> just allocated by nvkm_device_pci_new(). This leaks both the device<br /> wrapper and the pci_enable_device() reference taken inside it.<br /> <br /> Jump to the existing fail_nvkm label so nvkm_device_del() runs and<br /> balances both. The leak was introduced when the intermediate<br /> nvkm_device_del() between detection and aperture removal was dropped<br /> in favor of creating the pci device once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: disallow non-power of two min_region_sz on damon_start()<br /> <br /> Commit d8f867fa0825 ("mm/damon: add damon_ctx-&gt;min_sz_region") introduced<br /> a bug that allows unaligned DAMON region address ranges. Commit<br /> c80f46ac228b ("mm/damon/core: disallow non-power of two min_region_sz")<br /> fixed it, but only for damon_commit_ctx() use case. Still, DAMON sysfs<br /> interface can emit non-power of two min_region_sz via damon_start(). Fix<br /> the path by adding the is_power_of_2() check on damon_start().<br /> <br /> The issue was discovered by sashiko [1].

The Electron preload script in Logseq exposes an API method that allows the renderer process to invoke IPC handlers without proper path validation. An attacker with JavaScript execution in the renderer (e.g. via XSS or a malicious plugin), can read, write, or delete arbitrary files on the user&amp;#39;s system.<br /> While only version v0.10.15 was tested and confirmed as vulnerable, status of other versions is unknown since this issue was not addressed by a patch.

Logseq is vulnerable to a stored cross-site scripting (XSS). A malicious plugin can include a JavaScript payload in the "name" field of its "package.json" file, which is rendered using "innerHTML" without proper sanitization, allowing the execution of arbitrary code in the privileged host context.<br /> While only version v0.10.15 was tested and confirmed as vulnerable, status of other versions is unknown since this issue was not addressed by a patch.

Logseq is vulnerable to a sandbox escape flaw where plugins running in sandboxed iframes can inject arbitrary HTML attributes, such as event handlers, into their container element in the host DOM. Due to a disabled Content Security Policy (CSP), this allows a malicious plugin to execute arbitrary JavaScript in the privileged host context, potentially gaining unauthorized access to filesystem APIs.<br /> While only version v0.10.15 was tested and confirmed as vulnerable, status of other versions is unknown since this issue was not addressed by a patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE<br /> <br /> The current implementation incorrectly handles memory regions (MRs) with<br /> page sizes different from the system PAGE_SIZE. The core issue is that<br /> rxe_set_page() is called with mr-&gt;page_size step increments, but the<br /> page_list stores individual struct page pointers, each representing<br /> PAGE_SIZE of memory.<br /> <br /> ib_sg_to_page() has ensured that when i&gt;=1 either<br /> a) SG[i-1].dma_end and SG[i].dma_addr are contiguous<br /> or<br /> b) SG[i-1].dma_end and SG[i].dma_addr are mr-&gt;page_size aligned.<br /> <br /> This leads to incorrect iova-to-va conversion in scenarios:<br /> <br /> 1) page_size iova = 0x181800<br /> sg[0]: dma_addr=0x181800, len=0x800<br /> sg[1]: dma_addr=0x173000, len=0x1000<br /> <br /> Access iova = 0x181800 + 0x810 = 0x182010<br /> Expected VA: 0x173010 (second SG, offset 0x10)<br /> Before fix:<br /> - index = (0x182010 &gt;&gt; 12) - (0x181800 &gt;&gt; 12) = 1<br /> - page_offset = 0x182010 &amp; 0xFFF = 0x10<br /> - xarray[1] stores system page base 0x170000<br /> - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong)<br /> <br /> 2) page_size &gt; PAGE_SIZE (e.g., MR: 64K, system: 4K):<br /> ibmr-&gt;iova = 0x18f800<br /> sg[0]: dma_addr=0x18f800, len=0x800<br /> sg[1]: dma_addr=0x170000, len=0x1000<br /> <br /> Access iova = 0x18f800 + 0x810 = 0x190010<br /> Expected VA: 0x170010 (second SG, offset 0x10)<br /> Before fix:<br /> - index = (0x190010 &gt;&gt; 16) - (0x18f800 &gt;&gt; 16) = 1<br /> - page_offset = 0x190010 &amp; 0xFFFF = 0x10<br /> - xarray[1] stores system page for dma_addr 0x170000<br /> - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong)<br /> <br /> Yi Zhang reported a kernel panic[1] years ago related to this defect.<br /> <br /> Solution:<br /> 1. Replace xarray with pre-allocated rxe_mr_page array for sequential<br /> indexing (all MR page indices are contiguous)<br /> 2. Each rxe_mr_page stores both struct page* and offset within the<br /> system page<br /> 3. Handle MR page_size != PAGE_SIZE relationships:<br /> - page_size &gt; PAGE_SIZE: Split MR pages into multiple system pages<br /> - page_size

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: pressure: mprls0025pa: fix spi_transfer struct initialisation<br /> <br /> Make sure that the spi_transfer struct is zeroed out before use.