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-31659 |
6.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:batman-adv: reject oversized global TT response buffersbatadv_tt_prepare_tvlv_global_data() builds the allocation length for aglobal TT response in 16-bit temporaries. When a remote originatoradvertises a large enough global TT, the TT payload length plus the VLANheader offset can exceed 65535 and wrap before kmalloc().The full-table response path still uses the original TT payload length whenit fills tt_change, so the wrapped allocation is too small andbatadv_tt_prepare_tvlv_global_data() writes past the end of the heap objectbefore the later packet-size check runs.Fix this by rejecting TT responses whose TVLV value length cannot fit inthe 16-bit TVLV payload length field. | 2026-04-24 |
| CVE-2026-31654 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:mm/vma: fix memory leak in __mmap_region()commit 605f6586ecf7 ("mm/vma: do not leak memory when .mmap_prepareswaps the file") handled the success path by skipping get_file() viafile_doesnt_need_get, but missed the error path.When /dev/zero is mmap'd with MAP_SHARED, mmap_zero_prepare() callsshmem_zero_setup_desc() which allocates a new shmem file to back themapping. If __mmap_new_vma() subsequently fails, this replacementfile is never fput()'d - the original is released byksys_mmap_pgoff(), but nobody releases the new one.Add fput() for the swapped file in the error path.Reproducible with fault injection.FAULT_INJECTION: forcing a failure.name failslab, interval 1, probability 0, space 0, times 1CPU: 2 UID: 0 PID: 366 Comm: syz.7.14 Not tainted 7.0.0-rc6 #2 PREEMPT(full)Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014Call Trace: <TASK> dump_stack_lvl+0x164/0x1f0 should_fail_ex+0x525/0x650 should_failslab+0xdf/0x140 kmem_cache_alloc_noprof+0x78/0x630 vm_area_alloc+0x24/0x160 __mmap_region+0xf6b/0x2660 mmap_region+0x2eb/0x3a0 do_mmap+0xc79/0x1240 vm_mmap_pgoff+0x252/0x4c0 ksys_mmap_pgoff+0xf8/0x120 __x64_sys_mmap+0x12a/0x190 do_syscall_64+0xa9/0x580 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK>kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak)BUG: memory leakunreferenced object 0xffff8881118aca80 (size 360): comm "syz.7.14", pid 366, jiffies 4294913255 hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff c0 28 4d ae ff ff ff ff .........(M..... backtrace (crc db0f53bc): kmem_cache_alloc_noprof+0x3ab/0x630 alloc_empty_file+0x5a/0x1e0 alloc_file_pseudo+0x135/0x220 __shmem_file_setup+0x274/0x420 shmem_zero_setup_desc+0x9c/0x170 mmap_zero_prepare+0x123/0x140 __mmap_region+0xdda/0x2660 mmap_region+0x2eb/0x3a0 do_mmap+0xc79/0x1240 vm_mmap_pgoff+0x252/0x4c0 ksys_mmap_pgoff+0xf8/0x120 __x64_sys_mmap+0x12a/0x190 do_syscall_64+0xa9/0x580 entry_SYSCALL_64_after_hwframe+0x76/0x7eFound by syzkaller. | 2026-04-24 |
| CVE-2026-31653 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs: dealloc repeat_call_control if damon_call() failsdamon_call() for repeat_call_control of DAMON_SYSFS could fail if somehowthe kdamond is stopped before the damon_call(). It could happen, forexample, when te damon context was made for monitroing of a virtualaddress processes, and the process is terminated immediately, before thedamon_call() invocation. In the case, the dyanmically allocatedrepeat_call_control is not deallocated and leaked.Fix the leak by deallocating the repeat_call_control under thedamon_call() failure.This issue is discovered by sashiko [1]. | 2026-04-24 |
| CVE-2026-31652 |
7.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:mm/damon/stat: deallocate damon_call() failure leaking damon_ctxdamon_stat_start() always allocates the module's damon_ctx object(damon_stat_context). Meanwhile, if damon_call() in the function fails,the damon_ctx object is not deallocated. Hence, if the damon_call() isfailed, and the user writes Y to “enabled” again, the previouslyallocated damon_ctx object is leaked.This cannot simply be fixed by deallocating the damon_ctx object whendamon_call() fails. That's because damon_call() failure doesn't guaranteethe kdamond main function, which accesses the damon_ctx object, iscompletely finished. In other words, if damon_stat_start() deallocatesthe damon_ctx object after damon_call() failure, the not-yet-terminatedkdamond could access the freed memory (use-after-free).Fix the leak while avoiding the use-after-free by keeping returningdamon_stat_start() without deallocating the damon_ctx object afterdamon_call() failure, but deallocating it when the function is invokedagain and the kdamond is completely terminated. If the kdamond is not yetterminated, simply return -EAGAIN, as the kdamond will soon be terminated.The issue was discovered [1] by sashiko. | 2026-04-24 |
| CVE-2026-31650 |
7.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:mmc: vub300: fix use-after-free on disconnectThe vub300 driver maintains an explicit reference count for thecontroller and its driver data and the last reference can in theory bedropped after the driver has been unbound.This specifically means that the controller allocation must not bedevice managed as that can lead to use-after-free.Note that the lifetime is currently also incorrectly tied the parent USBdevice rather than interface, which can lead to memory leaks if thedriver is unbound without its device being physically disconnected (e.g.on probe deferral).Fix both issues by reverting to non-managed allocation of the controller. | 2026-04-24 |
| CVE-2026-31621 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:bnge: return after auxiliary_device_uninit() in error pathWhen auxiliary_device_add() fails, the error block callsauxiliary_device_uninit() but does not return. The uninit drops thelast reference and synchronously runs bnge_aux_dev_release(), which setsbd->auxr_dev = NULL and frees the underlying object. The subsequentbd->auxr_dev->net = bd->netdev then dereferences NULL, which is not agood thing to have happen when trying to clean up from an error.Add the missing return, as the auxiliary bus documentation states is arequirement (seems that LLM tools read documentation better than humansdo...) | 2026-04-24 |
| CVE-2026-31620 |
4.6 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:ALSA: usx2y: us144mkii: fix NULL deref on missing interface 0A malicious USB device with the TASCAM US-144MKII device id can have aconfiguration containing bInterfaceNumber=1 but no interface 0. USBconfiguration descriptors are not required to assign interface numberssequentially, so usb_ifnum_to_if(dev, 0) returns will NULL, which willthen be dereferenced directly.Fix this up by checking the return value properly. | 2026-04-24 |
| CVE-2026-31574 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:clockevents: Add missing resets of the next_event_forced flagThe prevention mechanism against timer interrupt starvation missed to resetthe next_event_forced flag in a couple of places: - When the clock event state changes. That can cause the flag to be stale over a shutdown/startup sequence - When a non-forced event is armed, which then prevents rearming before that event. If that event is far out in the future this will cause missed timer interrupts. - In the suspend wakeup handler.That led to stalls which have been reported by several people.Add the missing resets, which fixes the problems for the reporters. | 2026-04-24 |
| CVE-2026-31573 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:media: verisilicon: Fix kernel panic due to __initconst misuseFix a kernel panic when probing the driver as a module: Unable to handle kernel paging request at virtual address ffffd9c18eb05000 of_find_matching_node_and_match+0x5c/0x1a0 hantro_probe+0x2f4/0x7d0 [hantro_vpu]The imx8mq_vpu_shared_resources array is referenced by variantstructures through their shared_devices field. When built as amodule, __initconst causes this data to be freed after moduleinit, but it's later accessed during probe, causing a page fault.The imx8mq_vpu_shared_resources is referenced from non-init code,so keeping __initconst or __initconst_or_module here is wrong.Drop the __initconst annotation and let it live in the normal .rodatasection.A bug of __initconst called from regular non-init probe codeleading to bugs during probe deferrals or during unbind-bind cycles. | 2026-04-24 |
| CVE-2026-31567 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:PM: sleep: Drop spurious WARN_ON() from pm_restore_gfp_mask()Commit 35e4a69b2003f ("PM: sleep: Allow pm_restrict_gfp_mask()stacking") introduced refcount-based GFP mask management that warnswhen pm_restore_gfp_mask() is called with saved_gfp_count == 0.Some hibernation paths call pm_restore_gfp_mask() defensively wherethe GFP mask may or may not be restricted depending on the executionpath. For example, the uswsusp interface invokes it inSNAPSHOT_CREATE_IMAGE, SNAPSHOT_UNFREEZE, and snapshot_release().Before the stacking change this was a silent no-op; it now triggersa spurious WARNING.Remove the WARN_ON() wrapper from the !saved_gfp_count check whileretaining the check itself, so that defensive calls remain harmlesswithout producing false warnings.[ rjw: Subject tweak ] | 2026-04-24 |