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.

Year

Product

Score

Severity

Status

CVE

Score

Severity

Package

Description

Published

CVE-2026-35328

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

CVE-2026-35329

HIGH

strongswan

2026-10-10

CVE-2026-35330

HIGH

strongswan

2026-10-10

CVE-2026-35331

MEDIUM

strongswan

2026-10-10

CVE-2026-35332

HIGH

strongswan

2026-10-10

CVE-2026-35333

HIGH

strongswan

2026-10-10

CVE-2026-35334

HIGH

strongswan

2026-10-10

CVE-2026-98380

MEDIUM

kernel

In the Linux kernel, the following vulnerability has been resolved:net/sched: reject IDR error pointers when deleting actionstcf_action_delete() drops the reference held by its lookup before callingtcf_idr_delete_index() with the saved action index. An unlockedclassifier can remove that action and reserve the same IDR slot withERR_PTR(-EBUSY) in between.tcf_idr_delete_index() only checks the lookup result for NULL. Ittherefore treats the reservation as a tc_action and dereferencestcfa_bindcnt. A hardware execution breakpoint was used to schedule theinterleaving without changing the kernel source. KASAN reported thisdecoded trace: BUG: KASAN: null-ptr-deref in tca_action_gd+0x5b9/0x1010 Read of size 4 at addr 0000000000000010 by task poc/150 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002 RIP: tca_action_gd+0x5c0/0x1010: arch_atomic_read at arch/x86/include/asm/atomic.h:23 raw_atomic_read at include/linux/atomic/atomic-arch-fallback.h:457 atomic_read at include/linux/atomic/atomic-instrumented.h:33 tcf_idr_delete_index at net/sched/act_api.c:766 tcf_action_delete at net/sched/act_api.c:1859 tcf_del_notify at net/sched/act_api.c:2014 tca_action_gd at net/sched/act_api.c:2064 R13: 0000000000000010 R15: fffffffffffffff0 Kernel panic - not syncing: Fatal exceptionR15 contains ERR_PTR(-EBUSY), and adding the tcfa_bindcnt offset producesthe address in R13. With the guard applied, the same reproducer returned-ENOENT without a KASAN report or panic. Treat error pointers as absentand return -ENOENT.

2026-10-09

CVE-2026-98369

HIGH

kernel

In the Linux kernel, the following vulnerability has been resolved:xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for xfrm_trans_reinject()syzbot reported a suspicious RCU usage warning in ip6_pkt_drop(): WARNING: suspicious RCU usage in ip6_pkt_drop include/net/addrconf.h:389 suspicious rcu_dereference_check() usage! Call Trace: __in6_dev_get_safely include/net/addrconf.h:389 [inline] ip6_pkt_drop+0x596/0x610 net/ipv6/route.c:4620 ip6_pkt_discard+0x1c/0x30 net/ipv6/route.c:4651 xfrm_trans_reinject+0x324/0x630 net/xfrm/xfrm_input.c:806 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486When commit 4f4920669d21 ("xfrm: Reinject transport-mode packets throughworkqueue") converted xfrm_trans_reinject from a tasklet to a workqueue,the reinjection loop ceased running in softirq context. Workqueue workersrun in process context where local_bh_disable() does not enter an RCUread-side critical section under CONFIG_PREEMPT_RCU.Because finish callbacks (such as ip6_rcv_finish) expect to run under anRCU read lock (performing route lookups, l3mdev lookups, and accessingRCU-protected data structures), invoking them in workqueue context withoutrcu_read_lock() triggers RCU lockdep warnings.Furthermore, packets queued to the workqueue via xfrm_trans_queue_net()may carry non-refcounted (noref) dst entries (e.g. from ip_route_input_noref).Additionally, on netdevice unregistration, dst_dev_put() replaces dst->devwith blackhole_netdev, so dst entries do not keep skb->dev alive whilequeued in the workqueue.Fix these issues by:1. Calling skb_dst_force(skb) in xfrm_trans_queue_net() while still in the caller's RCU section to ensure dst is reference-counted before queuing.2. Holding a reference on skb->dev via dev_hold()/dev_put() across workqueue deferral so skb->dev remains valid during finish() callback processing.3. Acquiring rcu_read_lock() around the finish callback invocation loop in xfrm_trans_reinject().

2026-10-06

CVE-2026-98354

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