What were you trying to do that didn't work?

Auditing container infrastructure RPMs for binary hardening compliance. The slirp4netns binary has PIE and full RELRO but is missing stack canary protection and FORTIFY_SOURCE because the spec file uses bare ./configure instead of the RPM %configure macro, which skips injection of %{optflags} and %{build_ldflags}{}.

What is the impact of this issue to you?

slirp4netns provides user-mode networking for rootless containers. It creates a TAP device inside the container's network namespace and shuttles packets between the container and the host network stack. It runs unprivileged but processes raw network packets from container traffic — attacker-controlled input from any network-connected container process.

slirp4netns embeds a fork of libslirp, which has had multiple CVE-class buffer overflow vulnerabilities (CVE-2020-29129, CVE-2020-29130 — out-of-bounds access in slirp networking code). Without stack protector, a stack-based buffer overflow in the packet parsing path would not be detected at runtime. Without FORTIFY_SOURCE, buffer operations that could be bounds-checked at compile time are not.

The root cause is identical to crun (RHEL-152226): the spec file's %build section uses:
 
 
 ./configure --prefix=%{_usr} --libdir=%{_libdir}
The RPM %configure macro automatically injects CFLAGS="%{optflags}" and LDFLAGS="%{build_ldflags}", which include -fstack-protector-strong, -D_FORTIFY_SOURCE=2, and other standard RHEL hardening flags. Using bare ./configure bypasses all of this.

Please provide the package NVR for which the bug is seen:

slirp4netns-1.3.3-1.el10.x86_64

How reproducible is this bug?:

Always — the spec file uses ./configure instead of %configure.

Steps to reproduce

1. rpm2cpio slirp4netns-1.3.3-1.el10.x86_64.rpm | cpio -i --to-stdout ./usr/bin/slirp4netns 2>/dev/null > /tmp/slirp4netns
2. readelf -h /tmp/slirp4netns | grep Type — shows DYN (PIE present, correct)
3. readelf -d /tmp/slirp4netns | grep BIND_NOW — present (RELRO correct)
4. readelf -s /tmp/slirp4netns | grep stack_chk — no output (no stack canary)
5. readelf -s /tmp/slirp4netns | grep FORTIFY — no output (no FORTIFY_SOURCE)
6. Review spec file at https://gitlab.com/redhat/centos-stream/rpms/slirp4netns/-/blob/c10s/slirp4netns.spec — the %build section uses ./configure instead of %configure

Expected results

The spec file should use the RPM %configure macro, or explicitly pass hardening flags:
 
 
 {{# Option 1: Use %configure macro (preferred)
%configure --prefix=%{_usr} --libdir=%{_libdir}

1. Option 2: Explicit flags
   CFLAGS="%{optflags}" LDFLAGS="%{build_ldflags}" ./configure --prefix=%{_usr} --libdir=%{_libdir}}}
   Either approach would add -fstack-protector-strong, -D_FORTIFY_SOURCE=2, and other standard RHEL hardening flags to the binary.

   Actual results

The spec file uses bare ./configure which does not inject RPM hardening flags. The resulting /usr/bin/slirp4netns binary has PIE and full RELRO but no stack canary and no FORTIFY_SOURCE. This binary processes raw network packets from untrusted container traffic.

Note: This is the same root cause pattern as crun (RHEL-152226) and conmon (RHEL-152224) — container infrastructure C binaries missing hardening due to spec file not passing RPM build flags. fuse-overlayfs and passt also show zero stack canary and zero FORTIFY in their binaries but have different root causes that need further investigation.