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.

Year

Product

Score

Severity

Status

CVE

Score

Severity

Package

Description

Published

CVE-2026-35334

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-02

CVE-2026-16524

HIGH

performance_co-pilot

A command injection flaw in PCP's linux_sockets PMDA allows malicious shell metacharacters via the network.persocket.filter metric.This failed validation lets attackers execute arbitrary commands as the PMDA user when metrics refresh.

2026-07-30

CVE-2021-26142

HIGH

kernel

2026-07-27

CVE-2021-26147

HIGH

kernel

2026-07-27

CVE-2026-64600

HIGH

kernel

In the Linux kernel, the following vulnerability has been resolved:xfs: resample the data fork mapping after cycling ILOCKxfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode,a data fork mapping, and a cow fork mapping. Unfortunately, these twohelpers cycle the ILOCK to grab a transaction, which means that themappings are stale as soon as we reacquire the ILOCK. Currently werefresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, butwe don't refresh the data fork mapping beforehand, which means that thexfs_bmap_trim_cow in that function queries the refcount btree about thewrong physical blocks and returns an inaccurate value in *shared.If *shared is now false, the directio write proceeds with a stale datafork mapping. Fix this by querying the data fork mapping if thesequence counter changes across the ILOCK cycle.

2026-07-23

CVE-2026-50252

MEDIUM

unbound

In NLnet Labs Unbound 1.4.22 up to and including 1.25.1, UDP source port is randomized and intended to serve as a secret value that increases the entropy of DNS transactions. When resolver load balancing policies depend on the source port while their outcome is revealed this secrecy is undermined. The vulnerability arises when the load balancing policy is consistent with respect to the incoming source UDP port and IP address while heavily depending on the incoming source UDP port as a randomization source. When the SO_REUSEPORT configuration option is enabled ('so-reuseport: yes') in Unbound (by default), it meets these conditions, making it vulnerable for DNS cache poisoning attacks. Upon startup, Unbound randomly partitions the available UDP source port space into disjoint subsets of (almost) equal size, assigning each subset to a specific worker thread. When an incoming DNS query is received, the kernel’s SO_REUSEPORT load balancing mechanism deterministically assigns the query to a socket associated with a particular thread. All outgoing DNS queries generated during the resolution of that request use source ports selected exclusively from the port subset assigned to the corresponding thread. Since these port subsets are disjoint across threads, the source port observed in a resolver’s outgoing query to an authoritative name server serves as a reliable indicator of the worker thread that processed the original client query. A malicious actor can acquire the mapping between incoming UDP source ports (for a given fixed source IP address) and Unbound worker threads and leverage it to conduct DNS cache poisoning attacks by effectively lowering the random port population per thread.

2026-07-22

CVE-2026-50243

LOW

unbound

In NLnet Labs Unbound 1.6.2 up to and including 1.25.1, when Unbound is configured with the 'respip' module in front of the validator together with a 'response-ip' redirect rule or an RPZ file with an RPZ-IP trigger, the rewriting handler does not check the security status of the upstream answer and can instead rewrite a BOGUS A/AAAA answer to point to an operator's configured IP. If the validator finds an expired or otherwise invalid RRSIG on an answer whose A record falls within a 'response-ip'/RPZ configuration, the answer is still rewritten and given a hard coded security level of INSECURE. This results in the client receiving an INSECURE NOERROR reply rewritten by the operator's configured IP. A malicious actor can exploit the possible poisonous effect by spoofing a BOGUS A/AAAA answer that falls inside the operator's configured subnet rewrites. Such DNSSEC protected answers are then insecurely redirected to the operator's configured target.

2026-07-22

CVE-2026-59850

HIGH

libssh

A flaw was found in libssh. If data packets are processed after a channel is closed, channel data callbacks can be invoked after the associated data has already been freed, leading to crashes or possible use-after-free conditions.

2026-07-21

CVE-2026-59849

HIGH

libssh

A flaw was found in libssh. Logic errors in automatic certificate-based public key authentication can cause libssh clients to loop indefinitely when configured certificates are missing or repeatedly rejected by a server, leading to denial of service.

2026-07-21

CVE-2026-59847

HIGH

libssh

A flaw was found in libssh. Incorrect AES-GCM finalization checks in builds using the OpenSSL backend can effectively remove integrity protection, allowing an in-path attacker to modify plaintext on the wire without detection.

2026-07-21