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-35333 |
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-09-04 |
| CVE-2026-35332 |
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-09-04 |
| CVE-2026-35331 |
4.8 (i)
| MEDIUM | 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-09-04 |
| CVE-2026-35330 |
8.1 (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-09-04 |
| CVE-2026-35329 |
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-09-04 |
| CVE-2026-35328 |
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-09-04 |
| 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-09-02 |
| CVE-2026-74463 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlockFix a severe AB/BA deadlock between the Common Clock Framework (CCF)and the I2C adapter lock, which triggers when an I2C-controlled clockgenerator client (like the Si5351) is registered or modified under the CCF.During an i2c client clock (generator) frequency change, the CCF acquires its global'prepare_lock' mutex and the driver calls i2c_transfer() to update the client'schip registers, stalling for the adapter's I2C bus lock.Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIOexpander handling LEDs) can hold the I2C adapter lock. Inside this paralleltransfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the hostcontroller's input clock to calculate bus timings. This call attempts to acquirethe blocked CCF 'prepare_lock', creating a circular dependency that freezesthe system.The jz4780 host controller clock itself is static and never changes at runtime.However, calling clk_get_rate() inside the active transfer path introducesan unnecessary dependency on the CCF internal locks.Eliminate this synchronous clk_get_rate() call from the active transferpath by caching the static host peripheral clock rate once - inside the privatejz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed()to use this cached value, safely decoupling active I2C transactions from theCCF internal locks without any risk of stale timings.Assisted-by web based Google AI (pinpointing the bug and writing the message). | 2026-08-15 |
| CVE-2026-74462 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:i2c: imx: mark I2C adapter when hardware is powered downOn some i.MX platforms, certain I2C client drivers keep a periodicworkqueue which continues to trigger I2C transfers.During system suspend/resume, there exists a time window between: - suspend_noirq and the system entering suspend - the system starting to resume and resume_noirqIn this window, the I2C controller resources such as clock and pinctrlmay already be disabled or not yet restored.If a workqueue triggers an I2C transfer in this period, the driverattempts to access I2C registers while the hardware resources areunavailable, which may lead to system hang.Mark the I2C adapter as suspended during noirq suspend and block newtransfers until resume, ensuring that I2C transfers are only issuedwhen hardware resources are available. | 2026-08-15 |
| CVE-2026-74461 |
8.4 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:i2c: imx: Cancel hrtimer before clearing slave pointerIn i2c_imx_unreg_slave(), the slave pointer is set to NULL afterdisabling interrupts. However, a pending interrupt might alreadyhave started the hrtimer (i2c_imx_slave_timeout) before the pointerwas cleared. If the hrtimer fires after i2c_imx->slave is set toNULL, the timer callback i2c_imx_slave_finish_op() will calli2c_imx_slave_event() with a NULL slave pointer, which results in ause-after-free / NULL pointer dereference.Fix by canceling the hrtimer and waiting for it to complete afterdisabling interrupts, before clearing the slave pointer. | 2026-08-15 |