Search
Search Results (25 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| 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. | ||||