REDHAT-BUG-2550375: Buffer Overflow

Q: Who can trigger this issue?

A local process that can connect to the daemon's AF_UNIX data socket can trigger it. The client does not need to bind its own AF_UNIX socket before connecting.

Q: What happens on standard Fedora or RHEL builds?

With _FORTIFY_SOURCE enabled, as it is in Fedora and RHEL builds, the invalid copy is detected and the daemon aborts. This makes the issue a denial-of-service condition when an unbound client connects.

Q: Is the impact different in builds without _FORTIFY_SOURCE?

Yes. Without _FORTIFY_SOURCE, the same condition would cause a stack buffer overflow rather than an immediate fortified-library abort. Data left from an earlier bound-client connection can provide attacker-controlled source bytes for that overflow.

Published Oct 13, 2026

Updated

The clevis-pkcs11-afunix-socket-unlock daemon crashes when any AFUNIX client connects to the data socket without calling bind() first.

In main(), after accept() on the data socket, the daemon calls getpeername() to learn the client's address (lines 312-317). For an unbound client, getpeername() returns len = sizeof(safamilyt) = 2. The code then computes:

pathlen = len - offsetof(struct sockaddrun, sunpath); // 2 - 2 = 0

pathlen is socklent (unsigned). At line 320:

strncpy(peer, peeraddr.sunpath+1, pathlen-1); // 0 - 1 = UINT32MAX

This passes UINT32MAX as the copy length to strncpy on a 0-byte stack VLA. With FORTIFYSOURCE (enabled in all Fedora/RHEL builds), strncpychk detects the destination buffer size mismatch and calls abort(). Without FORTIFYSOURCE, this would be a stack buffer overflow.

Additionally, peeraddr (line 196) is never zeroed between loop iterations. A prior connection from a bound client leaves attacker-controlled data in peeraddr.sunpath, which becomes the source for the overflowing strncpy on the next (unbound) connection. This provides approximately 106 bytes of attacker-controlled source data, though FORTIFYSOURCE and stack canaries independently prevent exploitation beyond DoS.

The trigger is standard socket client behavior — any tool that calls connect() without bind() (socat, netcat, debugging scripts) will crash the daemon.

Affected file: src/pins/pkcs11/clevis-pkcs11-afunix-socket-unlock.c (lines 311-320) Versions affected: >= v21 through v22 (latest)

Steps to reproduce: 1. Start the daemon: clevis-pkcs11-afunix-socket-unlock -l /run/systemd/clevis-pkcs11-systemd.log -f /run/systemd/clevis-pkcs11.sock -s 0 -t 100 2. Connect without bind(): socat - UNIX-CONNECT:/run/systemd/clevis-pkcs11.sock < /dev/null 3. The daemon aborts with " buffer overflow detected : terminated" (exit code 134 / SIGABRT).

Affected Software

1 affected component

Red Hat Clevis>=v21<=v22

Event History

Oct 13, 2026

Data Sourced

via Red Hat·11:57 AM

DescriptionSeverityAffected Software

Frequently Asked Questions

Who can trigger this issue?

A local process that can connect to the daemon's AF_UNIX data socket can trigger it. The client does not need to bind its own AF_UNIX socket before connecting.

What happens on standard Fedora or RHEL builds?

With _FORTIFY_SOURCE enabled, as it is in Fedora and RHEL builds, the invalid copy is detected and the daemon aborts. This makes the issue a denial-of-service condition when an unbound client connects.

Is the impact different in builds without _FORTIFY_SOURCE?

Yes. Without _FORTIFY_SOURCE, the same condition would cause a stack buffer overflow rather than an immediate fortified-library abort. Data left from an earlier bound-client connection can provide attacker-controlled source bytes for that overflow.