When using a system with no malloc_usable_size(), zmalloc_size() assumed that the heap allocator always returns blocks that are long-padded. This may not always be the case, and will result with zmalloc_size() returning a size that is bigger than allocated. At least in one case this leads to out of bound write, process crash and a potential security vulnerability. Effectively this does not affect the vast majority of users, who use jemalloc or glibc.
Upstream pull request:
It is worth noting that the default Redis heap allocator on Linux is jemalloc: https://github.com/redis/redis#allocator.
The following products are not affected by this flaw because they use `jemalloc` as default heap allocator:
* Red Hat Enterprise Linux 8
* Red Hat Software Collections
* Red Hat Advanced Cluster Management for Kubernetes
Completed the analysis of the concerned vulnerability for both AAP 1.2 and Ansible Tower and below is my observation:
- Ansible Tower uses the RHEL Redis where both jemalloc() and zmalloc() are in use. However, "jemalloc()" being used as default Heap allocator.
- Ansible Core doesn't use redis, by default. There is the cache plugin that is optional and it doesn't directly make any choices about the heap allocator redis would use.
Hence, marking AAP 1.2 and Tower as "Affected" and "delegated".
Created redis tracking bugs for this issue:
Affects: epel-all [bug 1948769]
Affects: fedora-all [bug 1948770]