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-2022-21505 |
8.4 (i)
| HIGH | kernel | ** 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. | 2024-04-26 | ||||||||||||||||||||||||||
| CVE-2024-0874 |
5.3 (i)
| MEDIUM | coredns | A flaw was found in coredns. This issue could lead to invalid cache entries returning due to incorrectly implemented caching. | 2024-04-25 | ||||||||||||||||||||||||||
| CVE-2023-6237 |
7.5 (i)
| HIGH | openssl | Issue summary: Checking excessively long invalid RSA public keys may takea long time.Impact summary: Applications that use the function EVP_PKEY_public_check()to check RSA public keys may experience long delays. Where the key thatis being checked has been obtained from an untrusted source this may leadto a Denial of Service.When function EVP_PKEY_public_check() is called on RSA public keys,a computation is done to confirm that the RSA modulus, n, is composite.For valid RSA keys, n is a product of two or more large primes and thiscomputation completes quickly. However, if n is an overly large prime,then this computation would take a long time.An application that calls EVP_PKEY_public_check() and supplies an RSA keyobtained from an untrusted source could be vulnerable to a Denial of Serviceattack.The function EVP_PKEY_public_check() is not called from other OpenSSLfunctions however it is called from the OpenSSL pkey command lineapplication. For that reason that application is also vulnerable if usedwith the '-pubin' and '-check' options on untrusted data.The OpenSSL SSL/TLS implementation is not affected by this issue.The OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue. | 2024-04-25 | ||||||||||||||||||||||||||
| CVE-2024-26926 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:binder: check offset alignment in binder_get_object()Commit 6d98eb95b450 ("binder: avoid potential data leakage when copyingtxn") introduced changes to how binder objects are copied. In doing so,it unintentionally removed an offset alignment check done through callsto binder_alloc_copy_from_buffer() -> check_buffer().These calls were replaced in binder_get_object() with copy_from_user(),so now an explicit offset alignment check is needed here. This avoidslater complications when unwinding the objects gets harder.It is worth noting this check existed prior to commit 7a67a39320df("binder: add function to copy binder object from buffer"), likelyremoved due to redundancy at the time. | 2024-04-25 | ||||||||||||||||||||||||||
| CVE-2024-26925 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: release mutex after nft_gc_seq_end from abort pathThe commit mutex should not be released during the critical sectionbetween nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GCworker could collect expired objects and get the released commit lockwithin the same GC sequence.nf_tables_module_autoload() temporarily releases the mutex to loadmodule dependencies, then it goes back to replay the transaction again.Move it at the end of the abort phase after nft_gc_seq_end() is called. | 2024-04-25 | ||||||||||||||||||||||||||
| CVE-2024-26924 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: do not free live elementPablo reports a crash with large batches of elements with aback-to-back add/remove pattern. Quoting Pablo: add_elem("00000000") timeout 100 ms ... add_elem("0000000X") timeout 100 ms del_elem("0000000X") <---------------- delete one that was just added ... add_elem("00005000") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat.Looking at the remove function there is a chance that we will drop arule that maps to a non-deactivated element.Removal happens in two steps, first we do a lookup for key k and return theto-be-removed element and mark it as inactive in the next generation.Then, in a second step, the element gets removed from the set/map.The _remove function does not work correctly if we have more than oneelement that share the same key.This can happen if we insert an element into a set when the set alreadyholds an element with same key, but the element mapping to the existingkey has timed out or is not active in the next generation.In such case its possible that removal will unmap the wrong element.If this happens, we will leak the non-deactivated element, it becomesunreachable.The element that got deactivated (and will be freed later) willremain reachable in the set data structure, this can result ina crash when such an element is retrieved during lookup (stalepointer).Add a check that the fully matching key does in fact map to the elementthat we have marked as inactive in the deactivation step.If not, we need to continue searching.Add a bug/warn trap at the end of the function as well, the removefunction must not ever be called with an invisible/unreachable/non-existentelement.v2: avoid uneeded temporary variable (Stefano) | 2024-04-25 | ||||||||||||||||||||||||||
| CVE-2024-26923 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix garbage collector racing against connect()Garbage collector does not take into account the risk of embryo gettingenqueued during the garbage collection. If such embryo has a peer thatcarries SCM_RIGHTS, two consecutive passes of scan_children() may see adifferent set of children. Leading to an incorrectly elevated inflightcount, and then a dangling pointer within the gc_inflight_list.sockets are AF_UNIX/SOCK_STREAMS is an unconnected socketL is a listening in-flight socket bound to addr, not in fdtableV's fd will be passed via sendmsg(), gets inflight count bumpedconnect(S, addr) sendmsg(S, [V]); close(V) __unix_gc()---------------- ------------------------- -----------NS = unix_create1()skb1 = sock_wmalloc(NS)L = unix_find_other(addr)unix_state_lock(L)unix_peer(S) = NS // V count=1 inflight=0 NS = unix_peer(S) skb2 = sock_alloc() skb_queue_tail(NS, skb2[V]) // V became in-flight // V count=2 inflight=1 close(V) // V count=1 inflight=1 // GC candidate condition met for u in gc_inflight_list: if (total_refs == inflight_refs) add u to gc_candidates // gc_candidates={L, V} for u in gc_candidates: scan_children(u, dec_inflight) // embryo (skb1) was not // reachable from L yet, so V's // inflight remains unchanged__skb_queue_tail(L, skb1)unix_state_unlock(L) for u in gc_candidates: if (u.inflight) scan_children(u, inc_inflight_move_tail) // V count=1 inflight=2 (!)If there is a GC-candidate listening socket, lock/unlock its state. Thismakes GC wait until the end of any ongoing connect() to that socket. Afterflipping the lock, a possibly SCM-laden embryo is already enqueued. And ifthere is another embryo coming, it can not possibly carry SCM_RIGHTS. Atthis point, unix_inflight() can not happen because unix_gc_lock is alreadytaken. Inflight graph remains unaffected. | 2024-04-25 | ||||||||||||||||||||||||||
| CVE-2024-26922 |
5.5 (i)
| MEDIUM | kernel | In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: validate the parameters of bo mapping operations more clearlyVerify the parameters ofamdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place. | 2024-04-23 | ||||||||||||||||||||||||||
| CVE-2024-3177 |
4.9 (i)
| MEDIUM | kubernetes | A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using containers, init containers, and ephemeral containers with the envFrom field populated. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with containers, init containers, and ephemeral containers with the envFrom field populated. | 2024-04-22 | ||||||||||||||||||||||||||
| CVE-2024-31745 |
7.5 (i)
| HIGH | libdwarf | Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2024-2002. Reason: This candidate is a duplicate of CVE-2024-2002. Notes: All CVE users should reference CVE-2024-2002 instead of this candidate. | 2024-04-19 |