Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

oracle-oval логотип

ELSA-2020-4542

Опубликовано: 10 нояб. 2020
Источник: oracle-oval
Платформа: Oracle Linux 8

Описание

ELSA-2020-4542: cryptsetup security, bug fix, and enhancement update (MODERATE)

[2.3.3-2]

  • patch: Fix possible memory corruption in LUKS2 validation code in 32bit library.
  • Resolves: #1872294

[2.3.3-1]

  • Update to cryptsetup 2.3.3
  • Resolves: #1796826 #1743891 #1785748

[2.3.1-1]

  • Update to cryptsetup 2.3.1
  • Resolves: #1796826 #1743891 #1785748

Обновленные пакеты

Oracle Linux 8

Oracle Linux aarch64

cryptsetup

2.3.3-2.el8

cryptsetup-devel

2.3.3-2.el8

cryptsetup-libs

2.3.3-2.el8

cryptsetup-reencrypt

2.3.3-2.el8

integritysetup

2.3.3-2.el8

veritysetup

2.3.3-2.el8

Oracle Linux x86_64

cryptsetup

2.3.3-2.el8

cryptsetup-devel

2.3.3-2.el8

cryptsetup-libs

2.3.3-2.el8

cryptsetup-reencrypt

2.3.3-2.el8

integritysetup

2.3.3-2.el8

veritysetup

2.3.3-2.el8

Связанные CVE

Связанные уязвимости

CVSS3: 7.8
ubuntu
больше 5 лет назад

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.

CVSS3: 7.8
redhat
больше 5 лет назад

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.

CVSS3: 7.8
nvd
больше 5 лет назад

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.

CVSS3: 7.8
debian
больше 5 лет назад

A vulnerability was found in upstream release cryptsetup-2.2.0 where, ...

github
больше 3 лет назад

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.