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-98164 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:KVM: x86/mmu: Check write tracking in all address spaceskvm_gfn_is_write_tracked() checks only the supplied memslot, but pagetracking is per-address-space and shadow pages are shared across alladdress spaces. With SMM, a GFN can therefore be write-tracked in oneaddress space and appear untracked through the other.Check the supplied slot first, then the slot for the other address space.This ensures all callers honor write tracking regardless of the activeaddress space. In particular, it prevents mmu_try_to_unsync_pages() frommarking an upper-level shadow page unsync and eventually triggering theBUG in pte_list_remove().[invert direction of the conditional. - Paolo] | 2026-09-29 |
| CVE-2026-98162 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:smb/server: fix tree connection leak in smb2_tree_connect()See the procedure below: smb2_tree_connect ksmbd_tree_conn_connect xa_store(&sess->tree_conns, tree_conn->id, tree_conn) ksmbd_counter_inc(KSMBD_COUNTER_TREE_CONNS) ksmbd_share_tree_conn_inc(sc) ksmbd_iov_pin_rsp // fail status.ret = KSMBD_TREE_CONN_STATUS_NOMEM // do not disconnect tree_connDisconnect the new tree connection if ksmbd_iov_pin_rsp() fails. | 2026-09-25 |
| CVE-2026-98161 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:nvdimm: pmem: keep PREFLUSH before data writespmem_submit_bio() records a REQ_PREFLUSH error, but continues to copy thebio data and can later overwrite the error with a successful REQ_FUA flush.That lets data writes run after a failed preflush and can complete the biosuccessfully despite the failed ordering barrier.Run the REQ_PREFLUSH flush synchronously before touching the bio data andcomplete the bio with the flush error if it fails. Keep asynchronous flushchaining for REQ_FUA. At that point, data copy has completed and the parentbio can wait for the chained flush bio. | 2026-09-25 |
| CVE-2026-98160 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix mismatched free of HalData in rtw_sdio_if1_init()padapter->HalData is allocated via vzalloc(), but incorrectly freedusing kfree() in the rtw_sdio_if1_init() error path. Using kfree() torelease this vmalloc-backed buffer can lead to memory corruption.Use rtw_hal_data_deinit() to pair the free correctly and freeHalData with vfree().The bug was first flagged by an experimental static analysis tool weare developing for kernel memory-management bugs. Manual inspectionconfirms that the issue is still present in current mainline.An x86_64 allyesconfig build showed no new warnings. As we do not havesuitable RTL8723BS SDIO hardware to test with, no runtime testing wasable to be performed. | 2026-09-25 |
| CVE-2026-100078 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mei: pass correct argument to functionThe first argument to iwl_mei_write_cyclic_buf() should be the cldevbut the q_head pointer is passed instead. Fix it. | 2026-09-25 |
| CVE-2026-100072 |
4.1 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:ACPI: platform: Use acpi_bus_get_primary_device()The acpi_get_first_physical_node() usage in acpi_platform_fill_resource()and acpi_create_platform_device() is generally unsafe because in theorythe device returned by it may be freed at any time [1].It is also inefficient because acpi_get_first_physical_node() is calledmultiple times for the same argument which can be avoided.Address these issues by using acpi_bus_get_primary_device() instead ofacpi_get_first_physical_node() and adjusting the code to call it justonce at the beginning of and acpi_create_platform_device() and dropthe device reference acquired by it upon the return from that function. | 2026-09-25 |
| CVE-2026-98156 |
7.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:drm/virtio: use the DMA API for resource backing on XenOn a Xen PV domain page addresses bear no relation to the real machineaddresses the host would have to use to reach it.virtio_ring.c handles this correctly, vring_use_map_api() returns truefor any xen_domain() regardless of VIRTIO_F_ACCESS_PLATFORM.virtio-gpu makes the same decision independently, but its copylooks only at the feature bit: bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev);QEMU does not set iommu_platform on virtio-vga by default, soVIRTIO_F_ACCESS_PLATFORM is not negotiated, use_dma_api is false, andvirtio_gpu_object_shmem_init() describes the framebuffer's backing pagesto the host with sg_phys(). Those are guest-physical addresses. In a PVdomain they resolve, on the host side, to pages belonging to some otherdomain, so the host scans out unrelated memory.Move the decision into virtio_gpu_use_dma_api() and give it thexen_domain() check, like vring_use_map_api() has. Thisadditionally enables the dma_sync_sgtable_for_device() calls invirtgpu_vq.c, which are required for correctness whenever swiotlbis in play.Reproduced with a Xen 4.21 PV dom0 nested inside QEMU 8.2 withvirtio-vga, on both a distro 6.8 kernel and 6.18 LTS. A PVH dom0works fine and doesn't need this fix because it is identity-mapped,only PV dom0s are affected. | 2026-09-25 |
| CVE-2026-98150 |
7.0 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:bpf: Fix BPF_F_CPU validation for sparse CPU IDsBPF_F_CPU stores the target CPU ID in the upper 32 bits of the mapoperation flags. bpf_map_check_op_flags() currently compares that IDwith num_possible_cpus(), which is the number of possible CPUs ratherthan a bound on CPU IDs.On an arm64 QEMU guest with a CPU device-tree hole, the possible CPUmask was 0,2-3. A userspace program using raw bpf() syscalls createsa BPF_MAP_TYPE_PERCPU_ARRAY and performs update and lookup operationsfor each CPU by setting BPF_F_CPU and the CPU ID in the flags.With the old check, CPU 1 is incorrectly accepted while valid CPU 3 isrejected with -ERANGE. The CPU 1 update then reaches the per-CPU mapaccess path and triggers: Unable to handle kernel paging request at virtual address ... pc : __pi_memcpy_generic+0x5c/0x22c lr : bpf_percpu_array_update+0x2dc/0x2e8 Call trace: __pi_memcpy_generic bpf_map_update_value map_update_elem __sys_bpfCheck the CPU ID against nr_cpu_ids and cpu_possible() instead. Thisrejects CPU IDs outside the valid range and CPUs absent from thepossible mask, while allowing valid sparse CPU IDs. | 2026-09-25 |
| CVE-2026-98143 |
7.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:accel: ethosu: Don't read the U65 rounding mode as a storage modeBits 15:14 of NPU_SET_{IFM,OFM}_PRECISION select the activation storagemode on U85 only. On U65 the same field holds the rounding mode, and thecommand stream parser has read it as a storage mode since the driver wasadded.That went unnoticed while unknown values fell through the switch, butnow that they are rejected, every U65 command stream that asks fornatural rounding (2) fails CMDSTREAM_BO_CREATE with -EINVAL. Mesa emitsit for average pooling, concatenation, split, unpack, strided slice, LUTand argmax, which is 72 failures of the Teflon test suite on an i.MX93.Truncating rounding (1) is misread as well: it picks the two-tileaddress path and computes a bogus feature map size from tile bases thecommand stream never set.Read the field as a storage mode only on the hardware where it is one. | 2026-09-25 |
| CVE-2026-98130 |
8.1 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:sctp: fix a TOCTOU race in SCTP_CMD_TIMER_STARTThe SCTP_CMD_TIMER_START handler checks timer_pending() before callingtimer_reduce(). The timer can expire and detach between these operations,causing timer_reduce() to rearm the timer without taking the associationreference required for the newly armed timer.The timer callback later unconditionally drops its association reference,which can leave the association reference count unbalanced and result inuse-after-free during association teardown.Use the return value of timer_reduce() to determine whether the timer wasactually armed. Take the association reference only when timer_reduce()successfully starts a new timer, closing the race between checking thetimer state and rearming it.This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI ZeroDay Initiative. | 2026-09-25 |