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-98354 |
4.7 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:RDMA/mad: Fix receive buffer leak when PKey enforcement failsib_mad_complete_recv() initializes mad_recv_wc->rmpp_list and then runsib_mad_enforce_security() before linking recv_buf onto that list. Onfailure it calls ib_free_recv_mad(), which only walks rmpp_list and freesthe ib_mad_private of every buffer found there. As the list is stillempty at that point, nothing is freed at all.The caller cannot clean up either: ib_mad_recv_done() sets recv to NULLright after ib_mad_complete_recv() returns, assuming the MAD layer tookownership of the buffer. Every MAD that fails the PKey check thereforeleaks one ib_mad_private (about 300 bytes per IB port MAD, ~2K for OPA),and a remote node can trigger this repeatedly by sending MADs with awrong PKey.Link recv_buf onto rmpp_list right after the list is initialized, so theerror path has something to free. | 2026-10-06 |
| CVE-2026-98353 |
4.7 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:RDMA/erdma: Use IRQ-safe XArray helpers for QP and CQ tablesLocked QP and CQ lookups from EQ interrupts can deadlock withcreate-path XArray updates. If an interrupt arrives while the createpath holds the plain xa_lock, the lookup spins forever trying toacquire the same lock.Use IRQ-safe XArray helpers for all QP and CQ create-path updates,including the GSI QP store and error paths. Initialize both arrays withXA_FLAGS_LOCK_IRQ so sleeping allocations preserve interrupt state. | 2026-10-06 |
| CVE-2026-98349 |
7.1 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:wifi: libipw: reject too-short beacon and probe responseslibipw_process_probe_response() and the libipw_network_init() call itmakes assume the frame contains the full 36-byte beacon and proberesponse prefix, but the ipw2100 and ipw2200 receive paths onlyestablish that a management frame carries the generic 24-bytethree-address header.libipw_network_init() then computes the information element length as stats->len - sizeof(*beacon)stats->len is a u16 and sizeof() has type size_t, so the subtraction isevaluated as size_t and wraps instead of going negative. Truncatingthat to the u16 length parameter of libipw_parse_info_param() yields65524 for a 24-byte beacon, and the parser then walks the receivebuffer as if it held almost 64 KiB of information elements, readingpast the allocation.Reject the frame before any fixed field is touched.Found by an AI-assisted review of length arithmetic in management frameparsers. Verified with a KUnit case under Generic KASAN on arm64 underQEMU; I do not have the hardware, so it is not tested on a real device. | 2026-10-06 |
| CVE-2026-98322 |
6.3 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_nat: fully initialise new_addr in netmap setupnft_nat_setup_netmap() builds the mapped address in an on-stackunion nf_inet_addr. For an IPv4 mapping it writes only the 4-byte .ipmember and the loop runs a single 32-bit iteration, but it then copiesthe whole 16-byte union into range->min_addr and range->max_addr, so theupper 12 bytes reach nf_nat_setup_info() uninitialised.KMSAN reports an uninit-value in nf_nat_setup_info() reached fromnft_nat_eval(). The IPv6 path fills all 16 bytes and is not affected.Zero-initialise new_addr. | 2026-10-06 |
| CVE-2026-98261 |
8.1 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server use-after-free in cifs_chan_skip_or_disable()When a secondary channel is no longer supported by the server,cifs_chan_skip_or_disable() drops the channel reference withcifs_put_tcp_session() and then continues to use the server pointer bycalling cifs_signal_cifsd_for_reconnect() on it and reading itsprimary_server pointer. cifs_put_tcp_session() can drop the lastreference of the channel and tear it down, so both the channel and theprimary server (whose reference is also dropped bycifs_put_tcp_session()) can be freed before they are signaled forreconnect.Signal the channel and the primary server and capture the primaryserver pointer before dropping the channel reference withcifs_put_tcp_session(). | 2026-10-06 |
| CVE-2026-98260 |
7.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:exec: Cleanup POSIX timers right after de_thread()A per-thread CPU timer holds a reference to the PID of the thread it isattached to and, while it is armed, its node is queued in that thread'sposix_cputimers. The task is looked up by that PID.When a non-leader thread exec()s, de_thread() changes which task ownsthat PID. pid_task(timer->it.cpu.pid, PIDTYPE_PID) then returns NULL,but the node is still queued on tsk, which is alive. timer_lock_sighand()takes a failed lookup to mean that the node is already dequeued, so ithas nothing to undo.begin_new_exec() calls posix_cpu_timers_exit(me) right afterexec_task_namespaces() and that removes the leftover node, so the statenormally stays invisible. But bprm->point_of_no_return is set beforede_thread(), so if unshare_files(), set_mm_exe_file(), exec_mmap() orexec_task_namespaces() fails, the task dies before it gets there.exit_itimers() then frees the k_itimer while its node is still queued,and reaping tsk later erases that freed node from the rbtree.In short: the non-leader thread B the parent timer_create(CLOCK_THREAD_CPUTIME_ID) timer_settime() arm_timer() // the node is queued on B execve() de_thread(B) exchange_tids(B, leader) // B's PID now belongs to the leader release_task(leader) __exit_signal(leader) posix_cpu_timers_exit(leader) // cleans leader's queue, not B's __unhash_process(leader) // that PID has no task anymore exec_mmap() mmap_read_lock_killable(old_mm) kill(B, SIGKILL) // -EINTR get_signal() do_exit() exit_itimers() posix_timer_delete() posix_cpu_timer_del() posix_timer_unhash_and_free() // freed while still queued wait4() release_task(B) posix_cpu_timers_exit(B) cleanup_timerqueue() timerqueue_del() // use-after-freeMove the POSIX timer cleanup right after de_thread() before any of thelater failure conditions brings the task into do_exit().[ tglx: Move the cleanup right after de_thread() ] | 2026-10-06 |
| CVE-2026-98254 |
7.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:swiotlb: use the adjusted address for the highmem page lookupswiotlb_bounce() reads the page frame number from the slot's recordedorig_addr, then advances orig_addr by tlb_offset to reach the addressthe caller asked about. The highmem branch mixes the two: the offsetwithin the page comes from the adjusted address, the page from the valuebefore it.Once the adjustment crosses a page boundary the pair no longer describesone location, and the whole copy lands one page below the intended onefor a positive tlb_offset, one above for a negative one. DMA_FROM_DEVICEwrites the device data over the wrong page and leaves the intended onestale, DMA_TO_DEVICE feeds the device from a page the mapping may notcover. Partial syncs through dma_sync_single_range_for_*() are what maketlb_offset non-zero.The branch test is picked the same way, so a slot recorded in lowmem canbe adjusted into highmem and the lowmem path then hands a highmemaddress to phys_to_virt().Take both from orig_addr once it is final and keep pfn in the branchthat uses it. PhysHighMem() asks the question straight from the address,as dma-debug already does. | 2026-10-06 |
| CVE-2026-98168 |
5.1 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:smb: client: fix reparse buffer bounds in cifs_query_reparse_point()In cifs_query_reparse_point(), the start >= end check before casting tostruct reparse_data_buffer * only ensures the start pointer is within theresponse. It fails to verify that there is enough space remaining for thefixed 8-byte header of the structure.If a server provides a DataOffset that leaves less than 8 bytes remaining,the check passes, but subsequent reads of ReparseTag and ReparseDataLengthwill occur out-of-bounds.Fix this by ensuring the remaining space is at least the size of thereparse_data_buffer structure before accessing its fields. | 2026-10-06 |
| 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 |