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 reporting Known Exploitable Vulnerabilities (KEV) or new Security Vulnerabilities, please see our Vulnerability Response Policy or email our PSIRT team. Messages and attachments should be encrypted using PGP and a MontaVista PSIRT PGP key, which is available for download here.
| CVE | Score | Severity | Package | Description | Published |
|---|---|---|---|---|---|
| CVE-2026-99059 |
7.7 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:wireguard: noise: reject response consumption after intermediate initiationTwo threads begin processing the identical response message, receivedtwice. The first thread, A, runs. While it's running, the second one,B, gets partway through, and during that slow calculation, or even whileblocking on down_write(), A completes and then also a handshakeinitiation that's already been queued up runs in thread C, which itselftakes that same down_write(). The handshake initiation creationsucceeds, and sets the state back to waiting-for-response, and callsup_write(), at which point thread B resumes, because either its finishedits calculations or was finally allowed to acquire down_write(). ThreadB then copies the state back to the peer, and begins a new session,using that state, which is the same session as the one made in thread A.Thread A Thread B Thread Cdown_read() sA = handshake->state memcpy(cA, handshake->crypto)up_read()if (sA != 1) goto failslow_crypto(cA) down_read() sB = handshake->state memcpy(cB, handshake->crypto) up_read() if (sB != 1) goto fail slow_crypto(cB)down_write() if (sA != handshake->state) goto fail memcpy(handshake->crypto, cA) handshake->state = 2up_write()down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto)up_write() down_write() slow_crypto(handshake->crypto) handshake->state = 1 up_write() down_write() if (sB != handshake->state) goto fail memcpy(handshake->crypto, cB) handshake->state = 2 up_write() down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto) up_write()This seems basically impossible to hit in a meaningful way in practice,but ensure that it absolutely cannot happen by comparing the ephemeralprivate key that's on the stack with the latest one that the peer'shandshake state has. | 2026-10-23 |
| CVE-2026-99054 |
7.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:tipc: destroy topsrv workqueues before closing connectionstipc_topsrv_stop() closed subscriber connections while the topologyserver's send and receive workqueues were still running. Socketcallbacks and subscription events could then queue more work, andin-flight send/recv work could drop the last connection referenceduring the conn_idr walk.That race produced several teardown failures: refcount_t addition on0 from conn_get() on a connection whose release was blocked onidr_lock, a subsequent use-after-free in tipc_conn_close(),queue_work() on an already destroyed workqueue from the listenerdata-ready callback, and an RCU stall in tipc_topsrv_exit_net()while the walk spun under idr_lock.Clear srv->listener under idr_lock so it acts as a shutdown flag,skip queue_work() once it is NULL, destroy the workqueues to flushin-flight work, and only then close the remaining connections.Refuse tipc_conn_lookup() after that flag is cleared, and dropidr_lock when the teardown walk finds no connection, so anin-flight subscription event cannot pin idr_in_use while thewalk holds the lock.v3 supersedes the narrower in-thread diff Tung Quang Nguyenposted on 2026-09-23. It keeps his teardown order and adds thelookup refusal and the empty-idr unlock. | 2026-10-23 |
| CVE-2026-98965 |
7.5 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:ice: Restore Ordered MMIO Writes for Tx DoorbellsThe DQL accounting state which tracks the number of bytes queued for theNIC to transmit, namely dql->num_queued, is updated by the ICE driverwhen it invokes __netdev_tx_sent_queue(). Subsequently the driverupdates the hardware queue tail allowing the NIC to begin processing thework queue. The queue accounting update should be ordered before the NICbegins transmitting descriptors.The transmit path currently updates the hardware doorbell usingwritel_relaxed(), which (on arm64) does not provide the same orderingguarantees between writes to normal memory and writes to MMIO registersthat writel() does. This introduces a potential race where the NICbegins transmitting descriptors before the dql->num_queued update isglobally visible. If the NIC finishes before the update is observed bydql_completed(), it detects an invalid state where more bytes have beencompleted than have been queued. When this happens the following BUG_ONis triggered. BUG_ON(count > num_queued - dql->num_completed);This has been observed and manifests as the following crash (note thatthe trace has been trimmed) in an environment with sustained networkload that uses an Intel Corporation Ethernet Controller E810-XXV for SFP(rev 02) on an arm64 machine. Replacing writel_relaxed() with writel()in a test kernel eliminated the crash in the user's workload, whichpreviously reproduced the issue reliably. kernel BUG at lib/dynamic_queue_limits.c:99Internal error: Oops - BUG: 00000000f2000800 [#1] SMPpc : dql_completed+0x268/0x2a0lr : ice_clean_tx_irq+0x1d4/0x620 [ice]Call trace:dql_completed+0x268/0x2a0 (P)ice_napi_poll+0x94/0x520 [ice]__napi_poll+0x48/0x3f0net_rx_action+0x194/0x420This restores the behaviour prior to commit ccde82e90946 ("ice: add E830Earliest TxTime First Offload support"), which changed the notificationmechanism from writel() to writel_relaxed(). | 2026-10-23 |
| CVE-2026-98945 |
7.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:HID: steam: Rearrange teardown sequenceThis fixes a narrow window during the teardown sequence where callbackscould still be scheduled during cleanup that would then have a danglingpointer to the now-freed steam struct.This also puts work canceling for rumble and mode switch insteam_unregister, as that shouldn't persist while the client hdev is open. | 2026-10-23 |
| CVE-2026-111497 |
8.1 (i)
| HIGH | brotli ghostscript libcurl libjxl node.js | A buffer overflow vulnerability in the Brotli decoder (c/dec/decode.c) in Google Brotli versions 1.0.3 through 1.2.0 on all platforms allows a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code using a crafted Brotli-compressed stream.Users need to update any Brotli libraries or binaries between 1.0.3 through 1.2.0 to the latest available version: 1.0.10 or 1.1.1 or 1.2.1. | 2026-10-22 |
| CVE-2026-114406 |
6.8 (i)
| MEDIUM | ca-certificates | The system certificate authority (CA) store in Red Hat products, distributed via ca-certificates RPM packages, included multiple root CA certificates of authorities, which signed intermediate CA certificates with weak private keys issued by the eMudhra certificate authority. A man-in-the-middle attacker could use this flaw to issue certificates for arbitrary host names signed by the weak intermediate CA certificates, which would be considered trusted by a TLS/SSL client using system CA store and cause such clients to connect to malicious sites.Due to inability to only distrust specific intermediate certificates in all clients using the system CA store, root CA certificates of authorities that signed weak intermediate CA certificates are being removed. | 2026-10-21 |
| CVE-2026-109619 |
8.1 (i)
| HIGH | php | PHP has various global state that temporarily points into request memory. In some scenarios, global state may not be correctly reset, or may be repopulated after being reset. The global state may then refer to request memory even after it has been freed. Subsequent requests may read or branch on this stale state before it is fully initialized. Multiple strategies can trigger this condition and produce remote code execution (RCE). | 2026-10-21 |
| CVE-2026-109618 |
8.1 (i)
| HIGH | php | PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request. Some contexts may not properly account for this scenario and leave request memory in an uninitialized state before performing an allocation. The subsequent request cleanup procedure may read or branch on this memory. Multiple OOM strategies can consistently trigger this condition and lead to remote code execution (RCE). | 2026-10-21 |
| CVE-2026-111943 |
6.8 (i)
| MEDIUM | go | On most platforms, Go uses the given system root certificates. However, in some narrower cases, the system trust stores may not be updated without further action. To defend against the narrower set of cases that may remain affected, a denylist was added in crypto/x509 to return an error when calling Verify with any of the known intermediate certificates that are no longer considered to be trustworthy. | 2026-10-21 |
| CVE-2026-98863 |
7.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages failsRe-pend GET_NESTED_STATE_PAGES before exiting to userspace if getting thenested pages fails in the KVM_RUN path. If userspace re-runs the vCPU, andvmcs02 holds valid PFNs from the *previous* run of L2, then KVM couldre-enter L2 with stale, unpinned PFNs mapped into e.g. the vAPIC page.Note, both SVM and VMX (as of commit 11722439fb20 ("KVM: nVMX: EnsureKVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit") ensure the requestis cleared on VM-Exit (including the "forced" case), i.e. there is no riskof double-mapping due to emulated VMLAUNCH/VMRESUME/VMRUN *and* the requesttrying to map the nested pages. | 2026-10-18 |
