Are any Greenplum components or binaries impacted by CVE-2025-4802, which affects GNU glibc versions 2.27 to 2.38, allowing potential privilege escalation via LD_LIBRARY_PATH manipulation in statically linked setuid binaries calling dlopen().
Are there any patches, updates, or mitigation guidelines specific to Greenplum distributions.
R&D have found that Greenplum is not affected by CVE-2025-4802.
Brief recap of CVE-2025-4902:
If a statically-linked binary has setuid bit set, it might accidentally honor LD_LIBRARY_PATH and tries to load malicious libraries. Normally the dynamic loader of glibc identifies the risk and ignores untrusted LD_LIBRARY_PATH. But in the case of statically-linked binary, and the glibc version is between 2.27 to 2.38, that binary, and the glibc version is beween 2.27 to 2.38, that mechanism is not working and the vulnerability can be exploited.
The three most important premises of the CVE:
1. The binary is statically-linked.
- Greenplum server binaries (postgres, postmaster, etc.) are not statically linked.
2. The binary is compiled with glibc version 2.27 to 2.38.
3. The binary has setuid bit set (chmod u+s)
- No Greenplum components (whether server or components) should ever be shipped with setuid bit set.
Below are a few steps you can use to verify your system:
STEP 1
Check if the binary is statically-linked:
ldd /path/to/binary
If the outputs shared libraries, especially if it contains something like:
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f...)
That means that the glibc is dynamically loaded and it is not impacted.
STEP 2
If the binary is statically loaded check the version of the glibc:
strings /path/to/binary | grep 'GNU C Library'
If the glibc version is not between 2.27 and 2.38, then it's not impacted.
STEP 3
Check if the binary has setuid bit set:
ls -l /path/to/binary
If it doesn't have an "s" in the permission bits, like '-rwsr-xr-x', then it's not impacted.