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-98845 |
6.3 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:tpm: Disable TPM on null key name mismatchThe null key name check exists to protect against TPM reset attacks, soa mismatch should stop the device from serving further requests.Currently it does not disable the chip when it finds a mismatch.The mismatch is logged: tpm tpm0: null key integrity check failedbut the chip keeps serving commands: / # tpm2_getcap -c properties-fixed TPM_PT_FAMILY_INDICATOR: as UINT32: 0x08322e3000 as string: "2.0" ...tpm2_load_null() where the null key name check is run sets the chip asdisabled only if the rc is non zero. When the mismatch is seen, rc iszero at that point and it returns success. The other issue is that thecaller expects the null key handle to be populated when the functionreturns 0 which it does here without writing the handle and proceedsassuming the null key handle is valid.During the test, I noticed that tpm2_start_auth_session() uses theuninitialized stack value as the key handle since tpm2_load_null()returns 0 despite the integrity failure and proceeds withTPM2_CC_START_AUTH_SESS with this value as salt key handle.Set rc to -ENODEV on the mismatch. The error path then disables the chipand returns the correct code to the caller.Tested in QEMU with swtpm and CONFIG_TCG_TPM2_HMAC=y by makingTPM2_CC_CONTEXT_LOAD fail with TPM2_RC_INTEGRITY and changing the nameof the re-created null key. The chip is now disabled on the mismatch. | 2026-10-18 |
| CVE-2026-98751 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:tty: abort break signalling on hangupThe break ioctls can race with hangup and end up calling into a ttydriver for a device that is already gone or powered down.Drivers must handle this race, but TCSBRK and TCSBRKP should still beaborted to avoid calling back into the driver after a user-controlledtimeout (possibly even after the tty has been reopened).Note that drivers should disable any break state on shutdown so justreturn on hangup (calling break_ctl() again is racy and will most likelyfail for drivers handling the race). | 2026-10-18 |
| CVE-2026-98744 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: max98363: fix uninitialized stream_config->typestream_config is not initialized before being passed tosdw_stream_add_slave(). The type field may contain garbage and islater copied to stream->type by sdw_config_stream().Zero-initialize stream_config so type defaults to SDW_STREAM_PCM. | 2026-10-18 |
| CVE-2026-99999 |
8.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:ipv4: validate checksum_start before completing checksumIf a packet with bad checksum metadata gets into the ipv4 stack,skb_checksum_help can corrupt the network header and cause a bunch ofmischief.This was discovered and reported by Paulos, and has been reporoducedby others independently since.We really shouldn't allow such packets in, but as a defencein depth measure, let's also check before we complete the checksum.A more complete validation at input is forthcoming, but needs more work. | 2026-10-15 |
| CVE-2026-98431 |
4.7 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependencyCommit 51976c6cd786 ("RDMA/core: Provide rdma_user_mmap_disassociate()to disassociate mmap pages") introduced disassociation_lock to protectnew mmap registrations against uverbs_user_mmap_disassociate(), butcreated an ABBA deadlock: Thread A (mmap / fork): mmap_lock -> disassociation_lock Thread B (disassociate): disassociation_lock -> mmap_lockFix by removing disassociation_lock entirely and using the pre-existinghw_destroy_rwsem instead. hw_destroy_rwsem already provides the sameprotection: rdma_umap_open() and ib_uverbs_mmap() both usedown_read_trylock() before registering a new VMA, so holding hw_destroy_rwsemin uverbs_user_mmap_disassociate() is sufficient to block new registrations.trylock is used in both mmap paths (not blocking down_read) becausemmap_lock is already held on entry, and uverbs_user_mmap_disassociate()acquires mmap_lock internally — a blocking read would recreate the samedeadlock.The only caller that was not taking hw_destroy_rwsem for write wasrdma_user_mmap_disassociate(). Fix it to take the rwsem per-ufile whileiterating under lists_mutex. This is safe because ib_uverbs_close()releases hw_destroy_rwsem entirely before acquiring lists_mutex, so thetwo locks are never held simultaneously.lockdep warning: [ 776.654252] ====================================================== [ 776.655214] WARNING: possible circular locking dependency detected [ 776.656167] 6.18.0for-upstream_debug_94e244d9ccab #1 Not tainted [ 776.657114] ------------------------------------------------------ [ 776.658087] devlink/14824 is trying to acquire lock: [ 776.658879] ffff88811170c800 (&mm->mmap_lock){++++}-{4:4}, at: uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs] [ 776.660479] [ 776.660479] but task is already holding lock: [ 776.661460] ffff888142d92b08 (&file->disassociation_lock){+.+.}-{4:4}, at: uverbs_user_mmap_disassociate+0x39/0x780 [ib_uverbs] [ 776.663177] [ 776.663177] which lock already depends on the new lock. [ 776.663177] [ 776.664525] [ 776.664525] the existing dependency chain (in reverse order) is: [ 776.665724] [ 776.665724] -> #2 (&file->disassociation_lock){+.+.}-{4:4}: [ 776.666887] __mutex_lock+0x16d/0x2330 [ 776.667633] rdma_umap_open+0x129/0x280 [ib_uverbs] [ 776.668489] dup_mmap+0xa40/0x1790 [ 776.669170] copy_process+0x5dd2/0x6170 [ 776.669933] kernel_clone+0xb6/0x610 [ 776.670636] __do_sys_clone+0xb5/0xf0 [ 776.671354] do_syscall_64+0x70/0x12e0 [ 776.672083] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 776.672940] [ 776.672940] -> #1 (&mm->mmap_lock/1){+.+.}-{4:4}: [ 776.673985] down_write_nested+0x90/0x1e0 [ 776.674751] dup_mmap+0x201/0x1790 [ 776.675448] copy_process+0x5dd2/0x6170 [ 776.676180] kernel_clone+0xb6/0x610 [ 776.676904] __do_sys_clone+0xb5/0xf0 [ 776.677615] do_syscall_64+0x70/0x12e0 [ 776.678351] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 776.679239] [ 776.679239] -> #0 (&mm->mmap_lock){++++}-{4:4}: [ 776.680253] __lock_acquire+0x18c6/0x2ec0 [ 776.681018] lock_acquire+0x10e/0x2e0 [ 776.681742] down_read+0x95/0x430 [ 776.682395] uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs] [ 776.683436] uverbs_destroy_ufile_hw+0x1ae/0x270 [ib_uverbs] [ 776.684416] ib_uverbs_remove_one+0x22b/0x420 [ib_uverbs] [ 776.685371] remove_client_context+0xa6/0xf0 [ib_core] [ 776.686342] disable_device+0x12b/0x240 [ib_core] [ 776.687249] __ib_unregister_device+0x269/0x460 [ib_core] [ 776.688233] ib_unregister_device+0x21/0x30 [ib_core] [ 776.689140] mlx5r_remove+0xd0/0x170 [mlx5_ib] [ 776.689999] device_release_driver_internal+0x3b2/0x5---truncated--- | 2026-10-14 |
| CVE-2026-98406 |
4.7 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driverieee80211_set_bitrate_mask() checks if the interface is running viaieee80211_sdata_running(), but it does not check if the interface isstill present in the driver.When sdata is running but IEEE80211_SDATA_IN_DRIVER is not set, thecall reaches drv_set_bitrate_mask() in driver-ops.h which hits wlan1: Failed check-sdata-in-driver check, flags: 0x0 WARNING: net/mac80211/driver-ops.h:884 at drv_set_bitrate_maskSyzkaller triggers this via wext SIOCSIWRATE ioctl. The Call Trace showswext_ioctl_dispatch() in wext-core.c dispatching the ioctl, callingioctl_standard_call() for SIOCSIWRATE, which calls cfg80211_wext_siwrate()in wext-compat.c. That builds a bitrate mask and callsrdev_set_bitrate_mask() which ends up in ieee80211_set_bitrate_mask() incfg.c. The interface is marked running via SDATA_STATE_RUNNING butflags is 0, so check_sdata_in_driver() fails.When the interface is being torn down, or when wext ioctl is issuedduring interface bringup before drv_add_interface() sets IN_DRIVER, therunning check passes while IN_DRIVER is clear.Check IEEE80211_SDATA_IN_DRIVER in ieee80211_set_bitrate_mask() beforecalling the driver, returning -ENETDOWN. This avoids the WARN_ONCE indriver-ops.h and matches other cfg.c operations that bail early when notin driver.This change should be safe because wiphy mutex is held incfg80211_wext_siwrate() via guard(wiphy), and IN_DRIVER is set/clearedunder RTNL and wiphy paths in drv_add_interface() anddrv_remove_interface() in driver-ops.c, so the check is race-freeagainst driver add/remove. Returning -ENETDOWN is the same error othernot-running paths use and does not introduce new locking.[also add second syzbot report] | 2026-10-14 |
| CVE-2026-98390 |
4.1 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:x86/amd_node: Avoid divide by zero on virtualized systemsOn a virtualized system, the number of nodes does not have a relationship tothe number of roots. A Xen PVH dom0 can calculate roots_per_node as 0, whichcrashes with a divide by zero in: if (count++ % roots_per_node)because the underlying topology code on Xen ends up making num_nodes2 and num_roots 1 and the integer division result is 0.The issue is seen with Xen, but it could affect other systems.Set roots_per_node to 1 in this case. Print a firmware bug when this isperformed for non-virtualized systems. [ bp: Massage commit message. ] | 2026-10-14 |
| 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-10-10 |
| 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-10-10 |
| 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-10-10 |