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-89775 |
9.3 (i)
| CRITICAL | kernel | In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluationComputing the effects of a TLB invalidation involves looking atthe size of the mapping cached by the TLB. For S1 mappings such asVNCR, this is deducted from the combination of the base granule sizeand the mapping level.However, this implies that the S1 MMU is *on*. When the MMU is off,we indicate this with the level being set to a "creative" value of-127 (S1_MMU_DISABLED).This ends-up being misinterpreted by pgshift_level_to_ttl() as itdoesn't handle negative levels at all (the level is immediately castto a u8 and only the bottom two bits considered), leading to aninvalidation size of 0. Not helpful.Tidy-up pgshift_level_to_ttl() to handle these negative levels, andttl_to_size() to always return SZ_1G when no valid TTL is present.This allows the removal of open-coded checks for similar situations.Note that the check for a negative value not explicitely checking forS1_MMU_DISABLED is deliberate, so that actual negative levels introducedwith LVA2 and D128 can take the same path if we ever support them. | 2026-09-16 |
| CVE-2026-81015 |
7.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:platform/x86/amd/pmc: Fix LPS0 and debugfs leaks when STB init failsamd_pmc_probe() registers the LPS0 s2idle handler withacpi_register_lps0_dev() and creates the driver's debugfs directory beforecalling amd_stb_s2d_init(), which is the last step in probe that can fail.When amd_stb_s2d_init() fails (for example the S2D telemetry region cannotbe ioremapped on a long-running system, or the SMU rejects the S2D setup)the error path only calls pci_dev_put() and returns. This leavesamd_pmc_s2idle_dev_ops on the global lps0_s2idle_devops_head list and leaksthe debugfs directory, while the devm-managed resources backing the handlerare torn down.Reloading the module then walks the corrupted list inacpi_register_lps0_dev() and hits: list_add corruption. next->prev should be prev, but was NULL. kernel BUG at lib/list_debug.c:29! acpi_register_lps0_dev+0x44/0x80 amd_pmc_probe+0x224/0x380 [amd_pmc] platform_probe+0x67/0x90Even without a reload, the stale registration means the next s2idletransition calls into torn-down driver state.Unwind the debugfs directory and the LPS0 registration on theamd_stb_s2d_init() error path. acpi_unregister_lps0_dev() is safe to callunconditionally here: it is guarded on the same conditions asacpi_register_lps0_dev(), which is exactly what amd_pmc_remove() alreadyrelies on. | 2026-09-11 |
| CVE-2026-81012 |
8.4 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:platform/x86: hp-bioscfg: fix off-by-one write in hp_get_string_from_buffer()hp_get_string_from_buffer() clamps the converted string length againstthe destination buffer size with "size > dst_size", so when theconverted length is exactly equal to dst_size, conv_dst_size is leftat dst_size and the unconditional NUL terminator write dst[conv_dst_size] = 0;lands one byte past the destination buffer. This is the same shape ofbug as the previously fixed off-by-one in hp_convert_hexstr_to_str():the buffer is sized correctly for the content, but the terminatorwrite is never checked against that size.Fix by changing the comparison to ">=" so conv_dst_size is always leftwith room for the terminator.All fixed-size destinations that reach this function (path[512],current_value[512], current_password/current_value[64], and theper-entry buffers in encodings[][512] and prerequisites[][512]) areaffected. | 2026-09-11 |
| CVE-2026-81011 |
7.1 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:platform/x86: hp-bioscfg: pass validated element count to package parsersThe per-type package parsers are handed the wrong element count.hp_init_bios_package_attribute() validates obj->package.count and thencalls one of the five hp_populate_*_package_data() wrappers (string,integer, enumeration, ordered list, password). Each wrapper forwards acount to its hp_populate_*_elements_from_package() parser, but insteadof forwarding the validated obj->package.count it derives the countfrom elements[0]. elements[0] is the NAME field and is always anACPI_TYPE_STRING, so reading ->package.count from it in fact reads->string.length through the union acpi_object. The parsers thus boundthemselves against the length of the name string rather than againstthe real number of elements in the package.This is safe today because hp_init_bios_package_attribute() refuses anypackage that has fewer than the type's element count, so a parser onlyever runs on a full package and never reads past it regardless of thebogus bound.An upcoming change relaxes that check to accept shorter packages. Oncea parser can receive fewer elements than its per-type count, a boundtaken from the name length no longer reflects the array size, and the"elem < count" loop conditions and "elem + n >= count" sub-loop guardsread past the end of elements[] - an out-of-bounds heap read.Forward the validated obj->package.count to every *_package_data()wrapper so the parsers bound themselves against the real package size.This does not change behaviour for the packages that enumeratecorrectly today and is a prerequisite for accepting shorter packagessafely. | 2026-09-11 |
| CVE-2026-81010 |
7.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:io_uring/waitid: honor task_work cancellationio_waitid_cb() may run through the fallback task_work path whentask_work_add() can no longer queue work to the originating task. Thefallback runs from a kworker and io_uring marks such task work ascanceled through tw.cancel.io_waitid_cb() currently ignores tw.cancel and calls __do_wait().waitid is task-context dependent: __do_wait() performs child lookuprelative to current, and the retry path also usescurrent->signal->wait_chldexit. If the callback runs from the fallbackkworker, current is therefore not the task that submitted the request.Honor tw.cancel before entering __do_wait(). Complete the request with-ECANCELED and skip the siginfo copy, since canceled task work may runwithout the submitting task's userspace execution context.Keep the existing siginfo handling for normal waitid completion andexplicit cancellation. | 2026-09-11 |
| CVE-2026-81008 |
7.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:interconnect: Fix use after free in icc_get() and of_icc_get_by_index()In of_icc_get_by_index() and icc_get(), if the dynamic allocation forpath->name fails via kasprintf(), the error handling path directlycalls kfree(path) to free the path object and returns an error.However, prior to this point, path_find() calls path_init(), whichalready links the path's requests into the req_list of the respectiveinterconnect nodes via hlist_add_head(). Directly invoking kfree(path)leaves dangling pointers in the hlist. A subsequent call to icc_get()or icc_set_bw() will traverse or modify these corrupted lists, triggeringa slab use afterfree.KASAN report showing the vulnerability when reproducing via debugfs: BUG: KASAN: slab-use-after-free in path_find+0x6f8/0xcfc Write of size 8 at addr fff000000d43f748 by task sh/1 ... Call trace: kasan_report+0xac/0xfc path_find+0x6f8/0xcfc icc_get+0x148/0x380 icc_get_set+0xf8/0x2d0 ... Freed by task 1: kfree+0x1a0/0x4a4 icc_get+0x2cc/0x380 icc_get_set+0xf8/0x2d0Fix this by replacing kfree(path) with the proper teardown function,icc_put(path), which safely removes the requests from the req_list usinghlist_del() and drops the provider usage references before freeing thememory.Additionally, in icc_get(), ensure that the icc_lock mutex is releasedprior to calling icc_put(path) to avoid a deadlock, as icc_put()internally acquires the same lock. | 2026-09-11 |
| CVE-2026-81007 |
7.1 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:ipmi: ipmb: validate write message lengthipmb_write() read message fields before validating the length byte.A zero or short write can read uninitialized stack bytes.A length smaller than the SMBus header underflows the block write length.Require a non-empty buffer and the minimum IPMB request length.Also require the length byte plus payload before parsing the message. | 2026-09-11 |
| CVE-2026-81006 |
7.8 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:ipmi: Remove all sysfs files on registration failureipmi_add_smi() creates the nr_users and nr_msgs files before trying tocreate the maintenance_mode file. If that last creation fails, the errorpath removes only nr_users before dropping the final reference to theinterface.Remove nr_msgs as well so no sysfs attribute embedded in the freedinterface remains registered. | 2026-09-11 |
| CVE-2026-81004 |
8.4 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:ipmi:msghandler: Cancel work cleanly on an errorIf an error occurs during startup of an IPMI interface, it may havescheduled work to run. The work needs to be canceled before theinterface can be freed. | 2026-09-11 |
| CVE-2026-81003 |
8.1 (i)
| HIGH | kernel | In the Linux kernel, the following vulnerability has been resolved:net/iucv: filter frames in afiucv_hs_rcv() by ingress deviceafiucv_hs_rcv() selects a socket from iucv_sk_list by matching four 8-bytename fields in the transport header alone. No check is made against thenet_device the frame arrived on.This can cause a frame arriving on any netdev to be delivered to an AF_IUCVsocket. Three problems follow.First, a frame arriving over HiperSockets can be delivered to a socketbound to the classic z/VM IUCV transport, which has iucv->hs_dev == NULL.iucv_sock_bind() takes the classic path whenever the requested useridmatches iucv_userid, even on a guest that also has a HiperSockets devicecarrying the same identifier. The child socket created byafiucv_hs_callback_syn() for such a match inherits hs_dev = NULL andtransport = AF_IUCV_TRANS_HIPER, so the first send() on it returns -ENODEV.The socket delivered to accept() is unusable.Second, a frame arriving on one netdev can be delivered to a socket boundto a different IQD device. Which can lead to- Accept-queue exhaustion (DoS)- Attacker-controlled peer identity in the child socket- Data injection into existing sockets- Fabric noise on the IQD fabric, where bogus replies are sent- killing established connectionsThird, all AF_IUCV sockets live in init_net, as iucv_sock_alloc() callssk_alloc(&init_net, ...). But even frames arriving on netdev devices in anamespace can be delivered to an IUCV socket. So a process in anunprivileged user and network namespace holding only the CAP_NET_RAWcapability valid within that namespace can send a raw ETH_P_AF_IUCV frameon its own lo device and have it matched against init_net sockets.Fix all three by skipping any socket whose hs_dev does not match theingress device. A classic z/VM IUCV socket has hs_dev == NULL; the ingressdev is never NULL, so classic sockets are skipped automatically. An unboundHIPER socket also has hs_dev == NULL and is skipped. A bound HIPER socketis only reachable from the exact IQD device it was bound to. Because hs_devis always a device in init_net (iucv_sock_bind() scansfor_each_netdev_rcu(&init_net, ...) exclusively), a frame whose ingressdevice belongs to another namespace never matches any socket.Note that AF_IUCV over HiperSockets provides no per-connectionauthentication: no sequence numbers, no TLS, no nonce. The four name fieldsidentifying a connection are exchanged in plaintext on the sharedHiperSockets segment (VCHID). Any host on the same HiperSockets segmentcould spoof any frame type against an existing connection. That is aprotocol-level property unchanged by this patch. The fix reduces the attacksurface to peers present on the same HiperSockets segment. | 2026-09-11 |