MontaVista CVE List and Response
MontaVista continually monitors the security community and customers for threats. We follow the community on CVE scoring (NVD) and set fix priority accordingly for affected products. Please view the following CVEs that have been remediated or are in process by clicking the CVE Year to the left or use the CVE Filters below.
For inquiries regarding Security Vulnerabilities, please see our Vulnerability Response Policy or email our PSIRT team security@mvista.com. Email messages and attachments can be encrypted using PGP and a MontaVista PSIRT PGP key, which is available for download here.
| CVE | Score | Severity | Package | Description | Published |
|---|---|---|---|---|---|
| CVE-2026-35334 |
7.5 (i)
| HIGH | strongswan | ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. | 2026-08-18 |
| CVE-2026-73281 |
3.5 (i)
| LOW | openssh | In ssh-agent in OpenSSH before 10.5, some operations can occur remotely but were intended to occur only locally, including operations that add tokens or use keys. This is caused by misinteraction between agent locking and the session-bind@openssh.com extension. | 2026-08-11 |
| CVE-2026-72693 |
7.8 (i)
| HIGH | kbd | `openvt -u` is intended to identify the owner of the current VT and then execute `login` as that user from a privileged context. In the documented `kbrequest`/init usage, the ownership test in `authenticate_user()` relies on `stat("/proc/<pid>/fd/0")`. `stat()` on `/proc/<pid>/fd/0` follows the symlink to the underlying TTY device node. As a result, `buf.st_uid` reflects the owner of the TTY node rather than the owner of the process holding the file descriptor. If the TTY owner returns to `root` or the getty owner after logout while an unprivileged process still has `fd 0` attached to that TTY, the check can incorrectly treat that process as belonging to the privileged console owner. Once that check succeeds, the `-u` path executes a passwordless login as the selected user. In the documented `kbrequest`/init deployment using `openvt -us`, this can result in passwordless `login -f root` on the spawned VT. This report establishes that privilege escalation path for that documented deployment; it does not claim equivalent reachability for deployments that do not use `openvt -u` from a privileged `kbrequest`/init path. | 2026-08-11 |
| CVE-2026-6426 |
4.4 (i)
| MEDIUM | qemu | A type mismatch vulnerability was found in QEMU's vhost inflight migration VMState handling. The destination buffer size is stored as a uint64_t but read by the VMS_VBUFFER load path as a signed int32_t. On little-endian hosts, a crafted incoming migration state with bit 31 set causes the value to be interpreted as negative and then implicitly converted to a very large size_t, leading qemu_get_buffer() to copy migration-stream data beyond the bounds of the mmap-backed inflight region.This can result in a crash of the QEMU process or memory corruption. Exploitation requires control of the migration producer or write access to the migration channel, combined with a destination configured to use vhost inflight migration. | 2026-08-10 |
| CVE-2026-63622 |
7.8 (i)
| HIGH | libvirt | A flaw was found in libvirt. A local attacker, specifically a process running as the confined `swtpm` user, could exploit a symlink-following vulnerability in the `virFileChownFiles()` function. By planting a symbolic link within the `swtpm` state directory, the attacker could trick the root-level libvirt daemon into changing the ownership of an arbitrary file to the `swtpm` user. This allows for privilege escalation from the `swtpm` sandbox to root-level file ownership control. | 2026-08-10 |
| CVE-2026-68087 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:HID: wacom: use GFP_ATOMIC in wacom_wac_queue_flush()wacom_wac_queue_flush() is called via the .raw_event callback(wacom_raw_event → wacom_wac_pen_serial_enforce → wacom_wac_queue_flush).For USB HID devices, this callback is invoked from hid_irq_in(), whichis a URB completion handler running in atomic context. Using GFP_KERNELin this path can sleep, leading to a "scheduling while atomic" bug.Use GFP_ATOMIC instead. The existing code already handles allocationfailure by skipping the fifo entry and continuing. | 2026-08-10 |
| CVE-2026-68086 |
7.0 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:mm/khugepaged: write all dirty file folios when collapsing[There is no upstream commit, as this code was removed by upstream commit 044925f9b565 ("mm: fs: remove filemap_nr_thps*() functions and their users")]As-is, khugepaged and writable-file opening exclude each other. A filecannot be open writeable and have THPs (because the filesystem is not awareof them). khugepaged will never collapse file pages for files that areopened writeable. On an open(O_RDWR/O_WRONLY), the page cache for thatparticular file is dropped. This is fine because nothing could've beendirtied.However, there is an edge-case: collapse_file() might not be able tocoexist with concurrent writers, but it can coexist with dirty folios(from previous writers). Therefore, the following can happen:open(file, O_RDWR)write(file)close(file)madvise(file_mapping, MADV_COLLAPSE, some non-dirty range)open(file, O_RDWR) nr_thps > 0 truncate_inode_pages() /* THPs are cleared out, but so are the dirty folios */When this edge-case happens, there is data loss, as the dirty folios arefully discarded.Fix it by fully writing back the page cache (and waiting) when collapsingfile THPs. Doing so provides the guarantee that no dirty folio will beobserved while there are active THPs. To fully ensure this is safe, theinvalidate_lock needs to be held while doing the writeout, so thatdo_dentry_open()'s page cache truncation excludes this write-and-wait.As a side effect, move the nr_thps counter bumping outside the i_pageslock. This is correct since the counter itself is an atomic_t and theproducer <-> consumer correctness is provided by a full memory barrier:smp_mb() in collapse_file()/memory barrier implied by full ordering inget_write_access() -> atomic_inc_unless_negative(). | 2026-08-10 |
| CVE-2026-68085 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceledHCI_UART_SENDING bit in tx_state means write_work is pending and blocksqueueing it again. Currently this bit is not cleared when canceling thework in hci_uart_close(), which blocks future writes when device isreopened later if write_work was pending.Fix by clearing HCI_UART_SENDING when canceling the work.Also make clearing of tx_skb safe by using disable_work_sync +enable_work instead of just cancel_work_sync. hci_uart_flush() purgesthe proto tx queue so we can cancel the pending write_work there,instead of doing it just in hci_uart_close(). Re-enable and possiblyrequeue the work after queue flush. | 2026-08-10 |
| CVE-2026-18938 |
6.2 (i)
| MEDIUM | p11-kit | A flaw was found in p11-kit. A local attacker, or one with equivalent access to a reachable RPC channel, could exploit an integer overflow vulnerability. By sending specially crafted messages, the attacker can cause the system to miscalculate memory allocation for nested attributes. This leads to a memory corruption issue, specifically a heap out-of-bounds write, which can crash the p11-kit RPC parsing process, resulting in a Denial of Service (DoS). This vulnerability is only exploitable on 32 bit systems. | 2026-08-07 |
| CVE-2026-68480 |
8.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:x86/bugs: Make Safe-RET robust against interrupt injectionAn attacker injecting interrupts while the Safe-RET mitigation executeson machines affected by SRSO can neutralize the safe return sequence,potentially leading to data leakage through speculative execution.Fixup register state as if the Safe-RET sequence executed successfullyby "emulating" it, in a manner of speaking, and avoid executing a RETinstruction after returning from the interrupt. | 2026-08-06 |