CVE-2019-12904
Description
Libgcrypt 1.8.4's C AES implementation is vulnerable to a flush-and-reload side-channel attack because lookup tables are stored in shared memory.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Libgcrypt 1.8.4's C AES implementation is vulnerable to a flush-and-reload side-channel attack because lookup tables are stored in shared memory.
Vulnerability
In Libgcrypt 1.8.4, the C implementation of AES uses lookup tables (encT and decT) that are stored in the .rodata section of the ELF binary [1][3]. Because these tables are placed in read-only data that is shared between processes via the same physical memory page, any other process on the same system can access the physical address of the tables and monitor cache activity. This affects platforms where an assembly-language implementation is unavailable, forcing the use of the C fallback [3]. GCM mode also has similar table-based implementation vulnerability in the same version [2].
Exploitation
An attacker with the ability to run unprivileged code on the same physical machine can perform a flush-and-reload side-channel attack. The attacker first maps the shared library containing the AES tables, allowing them to obtain the physical address of the tables [3]. They then repeatedly flush the cached table lines from the CPU cache and reload them, measuring the time difference to infer which table indices were accessed by the victim process during AES encryption or decryption. This does not require any special privileges beyond the ability to execute code on the same system [3].
Impact
Successful exploitation allows the attacker to recover secret AES keys used by the victim process. The attack is a side-channel information disclosure (breach of confidentiality) that can compromise the security of any data encrypted or decrypted with the affected AES implementation. The attacker gains no code execution or file manipulation, but the secret key material can be extracted, undermining the cryptographic protection provided by Libgcrypt [1][3].
Mitigation
The fix was committed in the Libgcrypt repository as commit daedbbb5541cd8ecda1459d3b843ea4d92788762, which moves the AES lookup tables from the shared .rodata section to the private .data section and marks them as volatile with cache-line alignment to prevent sharing between processes [1]. A similar fix for GCM tables was committed in a4c561aab1014c3630bc88faf6f5246fee16b020 [2]. The fixed version was released in Libgcrypt 1.8.5. Users should upgrade to version 1.8.5 or later. No workaround is available; updating the library is the recommended mitigation.
AI Insight generated on May 26, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
6- Libgcrypt/Libgcryptdescription
- Range: = 1.8.4
- osv-coords4 versionspkg:rpm/opensuse/libgcrypt&distro=openSUSE%20Leap%2015.0pkg:rpm/opensuse/libgcrypt&distro=openSUSE%20Tumbleweedpkg:rpm/suse/libgcrypt&distro=SUSE%20Linux%20Enterprise%20Module%20for%20Basesystem%2015pkg:rpm/suse/libgcrypt&distro=SUSE%20Linux%20Enterprise%20Module%20for%20Basesystem%2015%20SP1
< 1.8.2-lp150.5.10.1+ 3 more
- (no CPE)range: < 1.8.2-lp150.5.10.1
- (no CPE)range: < 1.9.4-1.2
- (no CPE)range: < 1.8.2-6.17.1
- (no CPE)range: < 1.8.2-8.6.2
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"The C implementation of AES and GCM in Libgcrypt uses shared look-up tables that are vulnerable to flush-and-reload side-channel attacks."
Attack vector
An attacker can perform a flush-and-reload side-channel attack by monitoring the physical memory access patterns of the shared look-up tables used by the AES and GCM implementations. Because these tables were previously shared between processes, an attacker could infer sensitive cryptographic information by observing cache hits and misses. This vulnerability is specific to platforms where the assembly-language implementation is unavailable, forcing the use of the C implementation [ref_id=1].
Affected code
The vulnerability affects the C implementation of AES and GCM look-up tables. Specifically, the tables defined in the AES implementation and the GCM look-up tables were modified to be encapsulated within structures to facilitate memory unsharing [ref_id=1, ref_id=2].
What the fix does
The patch mitigates the vulnerability by moving the look-up tables into a struct that includes volatile counter fields and enforcing 64-byte alignment [ref_id=1, ref_id=2]. By incrementing these counters, the implementation triggers copy-on-write behavior, which effectively unshares the memory pages between processes. This prevents an attacker from observing cache-based side channels on the shared memory pages. Additionally, the changes ensure that the tables are not subject to same-page merging algorithms that could be exploited [ref_id=1, ref_id=2].
Preconditions
- configThe system must be using the C implementation of AES or GCM, typically because an assembly-language implementation is unavailable.
- networkThe attacker must be able to execute code on the same physical hardware to monitor cache state across processes.
Generated on Jun 1, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
5- lists.opensuse.org/opensuse-security-announce/2019-07/msg00049.htmlmitrevendor-advisoryx_refsource_SUSE
- dev.gnupg.org/T4541mitrex_refsource_MISC
- github.com/gpg/libgcrypt/commit/a4c561aab1014c3630bc88faf6f5246fee16b020mitrex_refsource_MISC
- github.com/gpg/libgcrypt/commit/daedbbb5541cd8ecda1459d3b843ea4d92788762mitrex_refsource_MISC
- lists.apache.org/thread.html/rf9fa47ab66495c78bb4120b0754dd9531ca2ff0430f6685ac9b07772%40%3Cdev.mina.apache.org%3Emitremailing-listx_refsource_MLIST
News mentions
0No linked articles in our index yet.