CVE-2026-109969: Clevis: clevis: no authentication on pkcs#11 af_unix sockets allows key injection under permissive umask
A flaw was found in the clevis PKCS#11 pin. The clevis-pkcs11-afunix-socket-unlock daemon creates AFUNIX sockets without explicit permission restrictions or peer credential verification. Under a permissive process umask, any local user can connect to the control socket and inject arbitrary device/key pairs, or connect to the data socket to receive LUKS passphrases.
Other sources
The clevis-pkcs11-afunix-socket-unlock daemon creates two AFUNIX sockets (data socket at /run/systemd/clevis-pkcs11.sock and control socket at /run/systemd/clevis-pkcs11.control.sock) with no explicit permission restrictions and no peer credential verification. There is no umask(0077) before bind(), no fchmod() after bind(), and no SOPEERCRED check on accepted connections.
The data socket delivers LUKS passphrases to connecting processes. The control socket accepts arbitrary device/key pair injections from connecting processes. Socket permissions depend entirely on the inherited process umask — under systemd's default UMask=0022, sockets get mode 0755 which prevents unprivileged connect() (write permission required for AFUNIX stream sockets). However, in the dracut initramfs path or under a permissive umask, any process can connect and inject keys or receive passphrases.
The vulnerability is architectural: the code has zero authentication logic for its most critical function (key delivery), making the security posture entirely dependent on an inherited umask that is never verified in the code.
Affected files: src/pins/pkcs11/clevis-pkcs11-afunix-socket-unlock.c (controlthread and main socket handling) Versions affected: >= v21 through v22 (latest)
Steps to reproduce: 1. Start the daemon under permissive umask: (umask 0000; clevis-pkcs11-afunix-socket-unlock -l /run/systemd/clevis-pkcs11-systemd.log -f /run/systemd/clevis-pkcs11.sock -s 60 &) 2. Verify socket permissions: stat -c '%a' /run/systemd/clevis-pkcs11.control.sock shows 777 3. As non-root user, inject a key: echo -n "target-device,INJECTEDKEY" | socat - UNIX-CONNECT:/run/systemd/clevis-pkcs11.control.sock 4. The injected key is accepted and logged — no peer credential check is performed.
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Start the daemon with a restrictive umask of 0077 before it creates the AF_UNIX sockets, preventing unprivileged processes from connecting under a permissive inherited umask.
clevis-pkcs11-afunix-socket-unlock umask = 0077
Event History
Frequently Asked Questions
Which systems are exposed to unprivileged local users?
Systems are exposed when clevis-pkcs11-afunix-socket-unlock runs with a permissive inherited umask, which can make its AF_UNIX sockets accessible to local users. Under systemd's default UMask=0022, the sockets are mode 0755 and unprivileged users cannot connect because AF_UNIX stream connections require write permission.
What access does an attacker need?
An attacker needs local access and the ability to connect to the daemon's AF_UNIX sockets when their permissions permit it. No user interaction is required; a connection to the data socket can obtain LUKS passphrases, while a connection to the control socket can inject arbitrary device/key pairs.
Which socket paths should be checked during triage?
Check /run/systemd/clevis-pkcs11.sock, the data socket that delivers LUKS passphrases, and /run/systemd/clevis-pkcs11.control.sock, the control socket that accepts device/key pair input. Their permissions depend on the umask inherited by the daemon.
What configuration issue should be addressed if an update cannot be applied immediately?
Ensure the daemon is started with a restrictive umask rather than a permissive one. The described implementation does not set permissions after binding the sockets and does not verify peer credentials, so restricting socket accessibility through the inherited umask is the available mitigation described.