Filtered by vendor Linuxfoundation
Subscribe
Total
557 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-20049 | 5 Google, Linuxfoundation, Mediatek and 2 more | 47 Android, Yocto, Mt2713 and 44 more | 2026-06-17 | N/A | 4.4 MEDIUM |
| In flashc, there is a possible information disclosure due to an uncaught exception. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08541765; Issue ID: ALPS08541765. | |||||
| CVE-2024-20040 | 6 Google, Linux, Linuxfoundation and 3 more | 57 Android, Linux Kernel, Yocto and 54 more | 2026-06-17 | N/A | 8.8 HIGH |
| In wlan firmware, there is a possible out of bounds write due to improper input validation. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08360153 (for MT6XXX chipsets) / WCNCR00363530 (for MT79XX chipsets); Issue ID: MSV-979. | |||||
| CVE-2024-20023 | 5 Google, Linuxfoundation, Mediatek and 2 more | 27 Android, Yocto, Mt2713 and 24 more | 2026-06-17 | N/A | 6.7 MEDIUM |
| In flashc, there is a possible out of bounds write due to lack of valudation. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08541638; Issue ID: ALPS08541638. | |||||
| CVE-2024-20022 | 5 Google, Linuxfoundation, Mediatek and 2 more | 34 Android, Yocto, Mt2737 and 31 more | 2026-06-17 | N/A | 6.7 MEDIUM |
| In lk, there is a possible escalation of privilege due to a missing bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08528255; Issue ID: ALPS08528255. | |||||
| CVE-2023-6944 | 2 Linuxfoundation, Redhat | 2 Backstage, Red Hat Developer Hub | 2026-06-17 | N/A | 5.7 MEDIUM |
| A flaw was found in the Red Hat Developer Hub (RHDH). The catalog-import function leaks GitLab access tokens on the frontend when the base64 encoded GitLab token includes a newline at the end of the string. The sanitized error can display on the frontend, including the raw access token. Upon gaining access to this token and depending on permissions, an attacker could push malicious code to repositories, delete resources in Git, revoke or generate new keys, and sign code illegitimately. | |||||
| CVE-2023-52728 | 1 Linuxfoundation | 1 Onos-lib-go | 2026-06-17 | N/A | 5.5 MEDIUM |
| Open Networking Foundation SD-RAN ONOS onos-lib-go 0.10.25 allows an index out-of-range condition in putBitString. | |||||
| CVE-2023-52727 | 1 Linuxfoundation | 1 Onos-lib-go | 2026-06-17 | N/A | 8.1 HIGH |
| Open Networking Foundation SD-RAN ONOS onos-lib-go 0.10.25 allows an index out-of-range condition in parseAlignBits. | |||||
| CVE-2023-52726 | 1 Linuxfoundation | 1 Onos-ric-sdk-go | 2026-06-17 | N/A | 6.5 MEDIUM |
| Open Networking Foundation SD-RAN ONOS onos-ric-sdk-go 0.8.12 allows infinite repetition of the processing of an error (in the Subscribe function implementation for the subscribed indication stream). | |||||
| CVE-2023-52725 | 1 Linuxfoundation | 1 Onos-kpimon | 2026-06-17 | N/A | 6.5 MEDIUM |
| Open Networking Foundation SD-RAN ONOS onos-kpimon 0.4.7 allows blocking of the errCh channel within the Start function of the monitoring package. | |||||
| CVE-2023-52724 | 1 Linuxfoundation | 1 Onos-kpimon | 2026-06-17 | N/A | 8.1 HIGH |
| Open Networking Foundation SD-RAN onos-kpimon 0.4.7 allows out-of-bounds array access in the processIndicationFormat1 function. | |||||
| CVE-2023-51699 | 1 Linuxfoundation | 1 Fluid | 2026-06-17 | N/A | 4.0 MEDIUM |
| Fluid is an open source Kubernetes-native Distributed Dataset Orchestrator and Accelerator for data-intensive applications. An OS command injection vulnerability within the Fluid project's JuicefsRuntime can potentially allow an authenticated user, who has the authority to create or update the K8s CRD Dataset/JuicefsRuntime, to execute arbitrary OS commands within the juicefs related containers. This could lead to unauthorized access, modification or deletion of data. Users who're using versions < 0.9.3 with JuicefsRuntime should upgrade to v0.9.3. | |||||
| CVE-2023-47090 | 1 Linuxfoundation | 1 Nats-server | 2026-06-17 | N/A | 6.5 MEDIUM |
| NATS nats-server before 2.9.23 and 2.10.x before 2.10.2 has an authentication bypass. An implicit $G user in an authorization block can sometimes be used for unauthenticated access, even when the intention of the configuration was for each user to have an account. The earliest affected version is 2.2.0. | |||||
| CVE-2023-46742 | 1 Linuxfoundation | 1 Cubefs | 2026-06-17 | N/A | 4.8 MEDIUM |
| CubeFS is an open-source cloud-native file storage system. CubeFS prior to version 3.3.1 was found to leak users secret keys and access keys in the logs in multiple components. When CubeCS creates new users, it leaks the users secret key. This could allow a lower-privileged user with access to the logs to retrieve sensitive information and impersonate other users with higher privileges than themselves. The issue has been patched in v3.3.1. There is no other mitigation than upgrading CubeFS. | |||||
| CVE-2023-46741 | 1 Linuxfoundation | 1 Cubefs | 2026-06-17 | N/A | 4.8 MEDIUM |
| CubeFS is an open-source cloud-native file storage system. A vulnerability was found in CubeFS prior to version 3.3.1 that could allow users to read sensitive data from the logs which could allow them escalate privileges. CubeFS leaks configuration keys in plaintext format in the logs. These keys could allow anyone to carry out operations on blobs that they otherwise do not have permissions for. For example, an attacker that has succesfully retrieved a secret key from the logs can delete blogs from the blob store. The attacker can either be an internal user with limited privileges to read the log, or they can be an external user who has escalated privileges sufficiently to access the logs. The vulnerability has been patched in v3.3.1. There is no other mitigation than upgrading. | |||||
| CVE-2023-46740 | 1 Linuxfoundation | 1 Cubefs | 2026-06-17 | N/A | 6.5 MEDIUM |
| CubeFS is an open-source cloud-native file storage system. Prior to version 3.3.1, CubeFS used an insecure random string generator to generate user-specific, sensitive keys used to authenticate users in a CubeFS deployment. This could allow an attacker to predict and/or guess the generated string and impersonate a user thereby obtaining higher privileges. When CubeFS creates new users, it creates a piece of sensitive information for the user called the “accessKey”. To create the "accesKey", CubeFS uses an insecure string generator which makes it easy to guess and thereby impersonate the created user. An attacker could leverage the predictable random string generator and guess a users access key and impersonate the user to obtain higher privileges. The issue has been fixed in v3.3.1. There is no other mitigation than to upgrade. | |||||
| CVE-2023-46739 | 1 Linuxfoundation | 1 Cubefs | 2026-06-17 | N/A | 6.5 MEDIUM |
| CubeFS is an open-source cloud-native file storage system. A vulnerability was found during in the CubeFS master component in versions prior to 3.3.1 that could allow an untrusted attacker to steal user passwords by carrying out a timing attack. The root case of the vulnerability was that CubeFS used raw string comparison of passwords. The vulnerable part of CubeFS was the UserService of the master component. The UserService gets instantiated when starting the server of the master component. The issue has been patched in v3.3.1. For impacted users, there is no other way to mitigate the issue besides upgrading. | |||||
| CVE-2023-46738 | 1 Linuxfoundation | 1 Cubefs | 2026-06-17 | N/A | 6.5 MEDIUM |
| CubeFS is an open-source cloud-native file storage system. A security vulnerability was found in CubeFS HandlerNode in versions prior to 3.3.1 that could allow authenticated users to send maliciously-crafted requests that would crash the ObjectNode and deny other users from using it. The root cause was improper handling of incoming HTTP requests that could allow an attacker to control the ammount of memory that the ObjectNode would allocate. A malicious request could make the ObjectNode allocate more memory that the machine had available, and the attacker could exhaust memory by way of a single malicious request. An attacker would need to be authenticated in order to invoke the vulnerable code with their malicious request and have permissions to delete objects. In addition, the attacker would need to know the names of existing buckets of the CubeFS deployment - otherwise the request would be rejected before it reached the vulnerable code. As such, the most likely attacker is an inside user or an attacker that has breached the account of an existing user in the cluster. The issue has been patched in v3.3.1. There is no other mitigation besides upgrading. | |||||
| CVE-2023-46129 | 2 Linuxfoundation, Nats | 2 Nats-server, Nkeys | 2026-06-17 | N/A | 7.5 HIGH |
| NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing. The cryptographic key handling library, nkeys, recently gained support for encryption, not just for signing/authentication. This is used in nats-server 2.10 (Sep 2023) and newer for authentication callouts. In nkeys versions 0.4.0 through 0.4.5, corresponding with NATS server versions 2.10.0 through 2.10.3, the nkeys library's `xkeys` encryption handling logic mistakenly passed an array by value into an internal function, where the function mutated that buffer to populate the encryption key to use. As a result, all encryption was actually to an all-zeros key. This affects encryption only, not signing. FIXME: FILL IN IMPACT ON NATS-SERVER AUTH CALLOUT SECURITY. nkeys Go library 0.4.6, corresponding with NATS Server 2.10.4, has a patch for this issue. No known workarounds are available. For any application handling auth callouts in Go, if using the nkeys library, update the dependency, recompile and deploy that in lockstep. | |||||
| CVE-2023-43636 | 1 Linuxfoundation | 1 Edge Virtualization Engine | 2026-06-17 | N/A | 8.8 HIGH |
| In EVE OS, the “measured boot” mechanism prevents a compromised device from accessing the encrypted data located in the vault. As per the “measured boot” design, the PCR values calculated at different stages of the boot process will change if any of their respective parts are changed. This includes, among other things, the configuration of the bios, grub, the kernel cmdline, initrd, and more. However, this mechanism does not validate the entire rootfs, so an attacker can edit the filesystem and gain control over the system. As the default filesystem used by EVE OS is squashfs, this is somewhat harder than an ext4, which is easily changeable. This will not stop an attacker, as an attacker can repackage the squashfs with their changes in it and replace the partition altogether. This can also be done directly on the device, as the “003-storage-init” container contains the “mksquashfs” and “unsquashfs” binaries (with the corresponding libs). An attacker can gain full control over the device without changing the PCR values, thus not triggering the “measured boot” mechanism, and having full access to the vault. Note: This issue was partially fixed in these commits (after disclosure to Zededa), where the config partition measurement was added to PCR13: • aa3501d6c57206ced222c33aea15a9169d629141 • 5fef4d92e75838cc78010edaed5247dfbdae1889. This issue was made viable in version 9.0.0 when the calculation was moved to PCR14 but it was not included in the measured boot. | |||||
| CVE-2023-43635 | 1 Linuxfoundation | 1 Edge Virtualization Engine | 2026-06-17 | N/A | 8.8 HIGH |
| Vault Key Sealed With SHA1 PCRs The measured boot solution implemented in EVE OS leans on a PCR locking mechanism. Different parts of the system update different PCR values in the TPM, resulting in a unique value for each PCR entry. These PCRs are then used in order to seal/unseal a key from the TPM which is used to encrypt/decrypt the “vault” directory. This “vault” directory is the most sensitive point in the system and as such, its content should be protected. This mechanism is noted in Zededa’s documentation as the “measured boot” mechanism, designed to protect said “vault”. The code that’s responsible for generating and fetching the key from the TPM assumes that SHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being checked. The issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs. This leads to several issues: • Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well as not sealing their keys at all, meaning the “vault” is not protected from an attacker. • SHA1 is considered insecure and reduces the complexity level required to unseal the key in machines which have their SHA1 PCRs enabled. An attacker can very easily retrieve the contents of the “vault”, which will effectively render the “measured boot” mechanism meaningless. | |||||