Total
10 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2009-3279 | 1 Qnap | 2 Ts-239 Pro Turbo Nas, Ts-639 Pro Turbo Nas | 2025-04-09 | N/A |
| The QNAP TS-239 Pro and TS-639 Pro with firmware 2.1.7 0613, 3.1.0 0627, and 3.1.1 0815 create a LUKS partition by using the AES-256 cipher in plain CBC mode, which allows local users to obtain sensitive information via a watermark attack. | ||||
| CVE-2009-3200 | 1 Qnap | 2 Ts-239 Pro Turbo Nas, Ts-639 Pro Turbo Nas | 2025-04-09 | N/A |
| The QNAP TS-239 Pro and TS-639 Pro with firmware 2.1.7 0613, 3.1.0 0627, and 3.1.1 0815 create an undocumented recovery key and store it in the ENCK variable in flash memory, which allows local users to bypass the passphrase requirement and decrypt the hard drive by reading this variable, deobfuscating the key, and running a cryptsetup luksOpen command. | ||||
| CVE-2023-36476 | 1 Nixos | 1 Calamares-nixos-extensions | 2024-11-27 | 7.9 High |
| calamares-nixos-extensions provides Calamares branding and modules for NixOS, a distribution of GNU/Linux. Users of calamares-nixos-extensions version 0.3.12 and prior who installed NixOS through the graphical calamares installer, with an unencrypted `/boot`, on either non-UEFI systems or with a LUKS partition different from `/` have their LUKS key file in `/boot` as a plaintext CPIO archive attached to their NixOS initrd. A patch is available and anticipated to be part of version 0.3.13 to backport to NixOS 22.11, 23.05, and unstable channels. Expert users who have a copy of their data may, as a workaround, re-encrypt the LUKS partition(s) themselves. | ||||
| CVE-2021-4122 | 2 Cryptsetup Project, Redhat | 2 Cryptsetup, Enterprise Linux | 2024-11-21 | 4.3 Medium |
| It was found that a specially crafted LUKS header could trick cryptsetup into disabling encryption during the recovery of the device. An attacker with physical access to the medium, such as a flash disk, could use this flaw to force a user into permanently disabling the encryption layer of that medium. | ||||
| CVE-2020-14382 | 4 Canonical, Cryptsetup Project, Fedoraproject and 1 more | 5 Ubuntu Linux, Cryptsetup, Fedora and 2 more | 2024-11-21 | 7.8 High |
| A vulnerability was found in upstream release cryptsetup-2.2.0 where, there's a bug in LUKS2 format validation code, that is effectively invoked on every device/image presenting itself as LUKS2 container. The bug is in segments validation code in file 'lib/luks2/luks2_json_metadata.c' in function hdr_validate_segments(struct crypt_device *cd, json_object *hdr_jobj) where the code does not check for possible overflow on memory allocation used for intervals array (see statement "intervals = malloc(first_backup * sizeof(*intervals));"). Due to the bug, library can be *tricked* to expect such allocation was successful but for far less memory then originally expected. Later it may read data FROM image crafted by an attacker and actually write such data BEYOND allocated memory. | ||||
| CVE-2020-11932 | 1 Canonical | 1 Subiquity | 2024-11-21 | 2.3 Low |
| It was discovered that the Subiquity installer for Ubuntu Server logged the LUKS full disk encryption password if one was entered. | ||||
| CVE-2019-13179 | 1 Calamares | 1 Calamares | 2024-11-21 | N/A |
| Calamares versions 3.1 through 3.2.10 copies a LUKS encryption keyfile from /crypto_keyfile.bin (mode 0600 owned by root) to /boot within a globally readable initramfs image with insecure permissions, which allows this originally protected file to be read by any user, thereby disclosing decryption keys for LUKS containers created with Full Disk Encryption. | ||||
| CVE-2019-13178 | 1 Calamares | 1 Calamares | 2024-11-21 | N/A |
| modules/luksbootkeyfile/main.py in Calamares versions 3.1 through 3.2.10 has a race condition between the time when the LUKS encryption keyfile is created and when secure permissions are set. | ||||
| CVE-2017-18191 | 2 Openstack, Redhat | 2 Nova, Openstack | 2024-11-21 | N/A |
| An issue was discovered in OpenStack Nova 15.x through 15.1.0 and 16.x through 16.1.1. By detaching and reattaching an encrypted volume, an attacker may access the underlying raw volume and corrupt the LUKS header, resulting in a denial of service attack on the compute host. (The same code error also results in data loss, but that is not a vulnerability because the user loses their own data.) All Nova setups supporting encrypted volumes are affected. | ||||
| CVE-2024-43378 | 1 Nixos | 1 Calamares-nixos-extensions | 2024-09-03 | 7.8 High |
| calamares-nixos-extensions provides Calamares branding and modules for NixOS, a distribution of GNU/Linux. Users who installed NixOS through the graphical installer who used manual disk partitioning to create a setup where the system was booted via legacy BIOS rather than UEFI; some disk partitions are encrypted; but the partitions containing either `/` or `/boot` are unencrypted; have their LUKS disk encryption key file in plain text either in `/crypto_keyfile.bin`, or in a CPIO archive attached to their NixOS initrd. `nixos-install` is not affected, nor are UEFI installations, nor was the default automatic partitioning configuration on legacy BIOS systems. The problem has been fixed in calamares-nixos-extensions 0.3.17, which was included in NixOS. The current installer images for the NixOS 24.05 and unstable (24.11) channels are unaffected. The fix reached 24.05 at 2024-08-13 20:06:59 UTC, and unstable at 2024-08-15 09:00:20 UTC. Installer images downloaded before those times may be vulnerable. The best solution for affected users is probably to back up their data and do a complete reinstallation. However, the mitigation procedure in GHSA-3rvf-24q2-24ww should work solely for the case where `/` is encrypted but `/boot` is not. If `/` is unencrypted, then the `/crypto_keyfile.bin` file will need to be deleted in addition to the remediation steps in the previous advisory. This issue is a partial regression of CVE-2023-36476 / GHSA-3rvf-24q2-24ww, which was more severe as it applied to the default configuration on BIOS systems. | ||||
Page 1 of 1.