realloc failed (segmentation fault) during xccdf eval

[pfuntner]

My team has tooling that uses openscap on various Linux distros and platforms. Starting today (2025-04-21), openscap has started to end abnormally in a redhat/ubi9 container:

[root@c58d2e82b7d0 /]# oscap xccdf eval  --profile xccdf_org.ssgproject.content_profile_stig --report /tmp/oscap.html /tmp/scap-security-guide-0.1.76/ssg-rhel9-ds.xml
--- Starting Evaluation ---

Title   Install AIDE
Rule    xccdf_org.ssgproject.content_rule_package_aide_installed
Ident   CCE-90843-4
Result  notapplicable

.
.
.

Title   Write Audit Logs to the Disk
Rule    xccdf_org.ssgproject.content_rule_auditd_write_logs
Ident   CCE-83705-4
Result  notapplicable

realloc failed !
Segmentation fault (core dumped)
[root@c58d2e82b7d0 /]#

Complete output: oscap.txt

We didn't have the problem with redhat/ubi9 on 2025-04-20 and Redhat 9 still continues to work fine on AWS EC2 instances, even on 2025-04-21. We're using oscap 1.3.10 on all systems.

I have an Ansible playbook (run-oscap-on-ubi9-playbook.yaml.gz) that recreates the scenario:

$ docker run -dit --rm --name ubi9 redhat/ubi9
$ ansible-playbook --connection docker -i ubi9, run-oscap-on-ubi9-playbook.yaml

The playbook takes care of installing openscap, et al, downloading the STIG profile, running openscap.

I ran oscap with debugging:

• --verbose INFO: info-verbose.txt
• --verbose DEVEL: devel-verbose.txt.gz

[pfuntner]

I think one of the root causes of this might be doing a realloc() on a buffer that's already been freed:

$ cat realloc1.c
#include <stdlib.h>
#include <stdio.h>

void *main(int argc, char **argv) {
  puts("malloc()");
  void* buf = malloc(1024*1024);
  puts("free()");
  free(buf);
  puts("realloc()");
  void* ret = realloc(buf, 2*1024*1024);
  puts("exit()");
}
$ ./realloc1
malloc()
free()
realloc()
Segmentation fault (core dumped)
$

[pfuntner]

I tried to use the steps at OpenSCAP Developer Manual in the ubi9 container but was unable to install many pre-req packages.

I used the steps to build OpenSCAP 1.4.3 on an EL9 cloud instance, copied the openscap tree with the built files to the container, and was able to run the built version, but it failed the same way.

[pfuntner]

I used the build with debugging, followed the steps at https://github.com/OpenSCAP/openscap/blob/main/docs/developer/developer.adoc#321-example, ran to the point of the abend, and did a where in gdb:

Title   Verify Permissions on /etc/audit/auditd.conf
Rule    xccdf_org.ssgproject.content_rule_file_permissions_etc_audit_auditd
Ident   CCE-89284-4
Result  notapplicable

realloc failed !

Thread 1 "oscap" received signal SIGSEGV, Segmentation fault.
0x00007af02e99df4d in xsltParseStylesheetExcludePrefix.part.0 () from /lib64/libxslt.so.1
Missing separate debuginfos, use: dnf debuginfo-install audit-libs-3.1.5-1.el9.x86_64 bzip2-libs-1.0.8-10.el9_5.x86_64 dbus-libs-1.12.20-8.el9.x86_64 glibc-2.34-125.el9_5.3.x86_64 keyutils-libs-1.6.3-1.el9.x86_64 krb5-libs-1.21.1-4.el9_5.x86_64 libacl-2.3.1-4.el9.x86_64 libattr-2.5.1-3.el9.x86_64 libblkid-2.37.4-20.el9.x86_64 libcap-ng-0.8.2-7.el9.x86_64 libcom_err-1.46.5-5.el9.x86_64 libcurl-minimal-7.76.1-31.el9.x86_64 libffi-3.4.2-8.el9.x86_64 libgcc-11.5.0-5.el9_5.x86_64 libgcrypt-1.10.0-11.el9.x86_64 libgpg-error-1.42-5.el9.x86_64 libnghttp2-1.43.0-6.el9.x86_64 libselinux-3.6-1.el9.x86_64 libtool-ltdl-2.4.6-46.el9.x86_64 libxcrypt-4.4.18-3.el9.x86_64 libxml2-2.9.13-6.el9_5.2.x86_64 libxslt-1.1.34-9.el9_5.2.x86_64 libyaml-0.2.5-7.el9.x86_64 libzstd-1.5.1-2.el9.x86_64 lua-libs-5.4.4-4.el9.x86_64 openssl-libs-3.2.2-6.el9_5.1.x86_64 p11-kit-0.25.3-3.el9_5.x86_64 pcre2-10.40-6.el9.x86_64 popt-1.18-8.el9.x86_64 rpm-libs-4.16.1.3-34.el9.x86_64 sqlite-libs-3.34.1-7.el9_3.x86_64 systemd-libs-252-46.el9_5.3.x86_64 xmlsec1-1.2.29-13.el9.x86_64 xmlsec1-openssl-1.2.29-13.el9.x86_64 xz-libs-5.2.5-8.el9_0.x86_64 zlib-1.2.11-40.el9.x86_64
(gdb) where
#0  0x00007af02e99df4d in xsltParseStylesheetExcludePrefix.part.0 ()
   from /lib64/libxslt.so.1
#1  0x00007af02e9a50c8 in xsltParseStylesheetProcess () from /lib64/libxslt.so.1
#2  0x00007af02e9a5fdd in xsltParseStylesheetUser () from /lib64/libxslt.so.1
#3  0x00007af02e9a610e in xsltParseStylesheetImportedDoc () from /lib64/libxslt.so.1
#4  0x00007af02e9a61e7 in xsltParseStylesheetFile () from /lib64/libxslt.so.1
#5  0x00007af02ebc7a16 in apply_xslt_path_internal (source=0x2f8603f0,
    xsltfile=0x7af02ec94ce3 "xccdf-report.xsl", params=0x23db36c0,
    path_to_xslt=0x7fff75aa8d85 "/root/openscap/xsl", stylesheet=0x7fff75aa6618)
    at /root/openscap/src/source/xslt.c:151
#6  0x00007af02ebc7d2d in oscap_source_apply_xslt_path (source=0x2f8603f0,
    xsltfile=0x7af02ec94ce3 "xccdf-report.xsl", outfile=0x12496a00 "/tmp/oscap.html",
    params=0x23db36c0, path_to_xslt=0x7fff75aa8d85 "/root/openscap/xsl")
    at /root/openscap/src/source/xslt.c:197
#7  0x00007af02ec2beaf in _app_xslt (infile=0x2f8603f0,
    xsltfile=0x7af02ec94ce3 "xccdf-report.xsl", outfile=0x12496a00 "/tmp/oscap.html",
    params=0x7fff75aa7700) at /root/openscap/src/XCCDF/xccdf_session.c:1453
#8  0x00007af02ec2bfc3 in _xccdf_gen_report (infile=0x2f8603f0,
    id=0x1078fd10 "xccdf_org.open-scap_testresult_xccdf_org.ssgproject.content_profile_stig",
 outfile=0x12496a00 "/tmp/oscap.html", show=0x7af02ec94cb9 "",
    sce_template=0x7af02ec94cb9 "",
    profile=0x1078f760 "xccdf_org.ssgproject.content_profile_stig")
    at /root/openscap/src/XCCDF/xccdf_session.c:1470
#9  0x00007af02ec2d8e9 in xccdf_session_export_all (session=0xfe0d0e0)
    at /root/openscap/src/XCCDF/xccdf_session.c:2045
#10 0x000000000040f936 in app_evaluate_xccdf (action=0x7fff75aa7880)
    at /root/openscap/utils/oscap-xccdf.c:736
#11 0x000000000040e56c in oscap_module_call (action=0x7fff75aa7880)
    at /root/openscap/utils/oscap-tool.c:278
#12 0x000000000040ea55 in oscap_module_process (module=0x41c880 <XCCDF_EVAL>, argc=8,
    argv=0x7fff75aa7b48) at /root/openscap/utils/oscap-tool.c:373
#13 0x0000000000411bac in main (argc=8, argv=0x7fff75aa7b48)
    at /root/openscap/utils/oscap.c:85
(gdb)

[james-bellamy]

I've noticed the same behavior - it seems to be due to the --report /tmp/oscap.html flag as removing it prevents the seg fault.

[pfuntner]

I've noticed the same behavior - it seems to be due to the --report /tmp/oscap.html flag as removing it prevents the seg fault.

Hi, James... very interesting! I'll try that out.

I'm starting to believe this has to do with the xslt package. I've seen failures when libxslt-1.1.34-9.el9_5.2.src.rpm is installed.

[pfuntner]

I made some progress by installing a more recent version of libxslt. I used https://mirror.stream.centos.org/9-stream/AppStream/x86_64/os/Packages/libxslt-1.1.34-12.el9.x86_64.rpm but I really don't want to do that.

[evgenyz]

Hey!

I made some progress

Does it mean that you no longer observe the problem or it fails somewhere else?

[pfuntner]

Hey!

I made some progress

Does it mean that you no longer observe the problem or it fails somewhere else?

It doesn't fail at all if I install the newer xslt version from the CentOS rpm repo but it's not an accepted practice with my team. It's viewed as cowboy patching and we prefer to want a newer package in the official service stream.

[evgenyz]

Okay. The libxslt component maintainer got notified (https://issues.redhat.com/browse/RHEL-88167). Closing the issue.

[pfuntner]

Okay. The libxslt component maintainer got notified (https://issues.redhat.com/browse/RHEL-88167). Closing the issue.

Thanks for the reference! I wasn't aware of this Jira database!