Bug 2462394 (CVE-2026-109968) - CVE-2026-109968 clevis: clevis: PKCS#11 LUKS passphrase logged in plaintext to world-readable file
Summary: CVE-2026-109968 clevis: clevis: PKCS#11 LUKS passphrase logged in plaintext t...
Keywords:
Status: NEW
Alias: CVE-2026-109968
Deadline: 2026-12-07
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-04-26 19:02 UTC by OSIDB Bzimport
Modified: 2026-10-14 09:03 UTC (History)
18 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-04-26 19:02:13 UTC
AI_ONLY_REPORT
package: clevis-21-9.el10
------
Summary: PKCS#11 LUKS passphrases written to world-readable log via  
clevis-pkcs11-afunix-socket-unlock control socket: the PKCS#11 unlock  
helper logs the full passphrase received over its control socket, and  
deployments that create the logfile with permissive read permissions expose  
that secret to local users.
Requirements to exploit: The system must use the PKCS#11 LUKS unlock flow  
in `clevis-21-9.el10`, `clevis-pkcs11-afunix-socket-unlock` must be started  
with logging enabled as in the shipped systemd/dracut entrypoints, an  
unlock attempt must send `<device>,<passphrase>` over the control socket,  
and the attacker must have local access sufficient to read the resulting  
logfile. The strongest exposure case occurs when the file is created with a  
permissive mode such as `0644` under a `022` umask.
Component affected: `clevis-21-9.el10` PKCS#11 LUKS unlock path in  
`src/pins/pkcs11/clevis-pkcs11-afunix-socket-unlock.c` (`control_thread()`  
and logfile creation in `main()`), with passphrase input supplied by  
`src/luks/systemd/clevis-luks-pkcs11-askpin.in`
Version affected: `clevis-21-9.el10` when the PKCS#11 LUKS unlock flow is  
enabled and the shipped helper is invoked with `-l`
Patch available: no released package fix established; proposed patch  
included below
Version fixed: unknown
Upstream coordination: Not notified.
CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N - 5.5 (MEDIUM)
AV:L - Exploitation requires local access to the host or equivalent  
access to the generated logfile.
AC:L - Once the PKCS#11 unlock flow writes the log entry, recovering the  
passphrase is straightforward.
PR:L - A low-privileged local account is sufficient when logfile  
permissions permit non-root reads.
UI:N - No further victim interaction is needed beyond the normal unlock  
flow producing the log entry.
S:U - The impact remains within the same system security scope.
C:H - Disclosure of a LUKS unlock passphrase can expose protected disk  
contents.
I:N - The observed behavior does not itself alter data.
A:N - The observed behavior does not itself reduce service availability.
Impact: Moderate. The flaw writes a LUKS passphrase to a cleartext log  
file, so the confidentiality impact can be high if a local non-root user  
can read that file. However, exploitation is limited to the PKCS#11 unlock  
path and the stronger "world-readable" exposure depends on runtime file  
permissions such as umask rather than a package-enforced mode. Under Red  
Hat severity guidance, that combination of sensitive disclosure plus local,  
configuration-dependent reachability fits Moderate better than Important.
Embargo: no
Reason: This is a local, configuration-dependent disclosure issue with  
straightforward mitigation by removing secret logging and/or enforcing  
restrictive logfile permissions. It does not present the kind of remotely  
exploitable compromise that typically warrants embargo.
Acknowledgement: Aisle Research
Vulnerability Details: In the PKCS#11 askpass flow,  
`clevis-luks-pkcs11-askpin` assembles `<systemd_device>,<passphrase>` and  
sends it to `/run/systemd/clevis-pkcs11.control.sock`:
```bash
devices_array+=("${systemd_device},${passphrase}")
echo -n "${devices_array[$ix]}" | socat  
UNIX-CONNECT:/run/systemd/clevis-pkcs11.control.sock -
```
`clevis-pkcs11-afunix-socket-unlock` then parses that message and logs both  
fields, including the passphrase itself:
```c
while((t = strtok(t, ","))) {
if (is_device) {
fprintf(logfile, "Adding device:%s\n", t);
insert_device(t);
is_device = 0;
} else {
fprintf(logfile, "Adding key:%s\n", t);
insert_key(t);
control_thread_info = 1;
}
}
```
The logfile passed via `-l` is opened without an explicit restrictive mode:
```c
logfile = fopen(lfile, "w+");
```
The shipped PKCS#11 entrypoints invoke this helper with log paths under  
`/run/systemd/`:
```bash
clevis-pkcs11-afunix-socket-unlock -l  
/run/systemd/clevis-pkcs11-systemd.log -f /run/systemd/clevis-pkcs11.sock  
-s 60
```
```sh
clevis-pkcs11-afunix-socket-unlock -l /run/systemd/clevis-pkcs11-dracut.log  
-f /run/systemd/clevis-pkcs11.sock -s 60 &
```
This establishes a direct secret-in-log condition: the passphrase is  
written verbatim to the logfile. Whether non-root users can read that  
logfile depends on runtime permissions and deployment defaults, but if the  
file is created with a permissive mode such as `0644`, the passphrase  
becomes readable to any local user. Even where the file is more tightly  
permissioned, the helper is still storing secret material in cleartext logs.
Steps to reproduce:
1. Use `clevis-21-9.el10` with the PKCS#11 LUKS askpass flow enabled.
2. Start the handler as shipped with `clevis-pkcs11-afunix-socket-unlock -l  
/run/systemd/clevis-pkcs11-systemd.log -f /run/systemd/clevis-pkcs11.sock  
-s 60`.
3. Send one test control message with  
`printf 'luks-test,MY_TEST_SECRET_123\n' | socat -  
UNIX-CONNECT:/run/systemd/clevis-pkcs11.control.sock`.
4. Run `grep 'Adding key:' /run/systemd/clevis-pkcs11-systemd.log` and  
observe `Adding key:MY_TEST_SECRET_123`.
5. Run `stat -c '%a %n' /run/systemd/clevis-pkcs11-systemd.log`; if the  
file is created as `0644` under a `022` umask, non-root local users can  
read the passphrase directly. If the mode is stricter, the underlying  
secret logging still occurs, but exposure is limited to principals that can  
read the logfile.
Mitigation: Until a fix is available, avoid passing `-l` to  
`clevis-pkcs11-afunix-socket-unlock` where operationally possible. If  
logging must remain enabled, invoke the helper under a restrictive umask  
and ensure the logfile is created with mode `0600` and readable only by  
trusted privileged users. Existing `/run/systemd/clevis-pkcs11-*.log` files  
should be treated as sensitive and removed after use.
Proposed Fix: Remove passphrase logging and create the logfile with  
restrictive permissions when logging is enabled.
```diff
diff --git a/src/pins/pkcs11/clevis-pkcs11-afunix-socket-unlock.c  
b/src/pins/pkcs11/clevis-pkcs11-afunix-socket-unlock.c
index 67ae893..9d5eabc 100644
— a/src/pins/pkcs11/clevis-pkcs11-afunix-socket-unlock.c
+++ b/src/pins/pkcs11/clevis-pkcs11-afunix-socket-unlock.c
@@ -27,6 +27,8 @@
#include <sys/un.h>
#include <sys/types.h>
#include <sys/socket.h>
+#include <sys/stat.h>
+#include <fcntl.h>
#include <unistd.h>
@@ -154,7 +156,7 @@ static void* control_thread(void *targ) {
insert_device(t);
is_device = 0;
} else {
               fprintf(logfile, "Adding key:%s\n", t);
+                fprintf(logfile, "Adding key:[REDACTED]\n");
                  insert_key(t);
                  control_thread_info = 1;
              }
@@ -230,7 +232,19 @@ int main(int argc, char* argv[]) {
              break;
          case 'l':
              strncpy(lfile, optarg, MAX_PATH - 1);

           logfile = fopen(lfile, "w+");
+            {
+                int fd = open(lfile, O_WRONLY | O_CREAT | O_TRUNC |  
O_CLOEXEC, 0600);
+                if (fd == -1) {
+                    perror("open logfile");
+                    exit(EXIT_FAILURE);
+                }
+                logfile = fdopen(fd, "w");
+                if (!logfile) {
+                    perror("fdopen logfile");
+                    close(fd);
+                    exit(EXIT_FAILURE);
+                }
+            }
              break;
```


------
This report was generated using AI technology. Always review AI-generated  
content prior to use


Note You need to log in before you can comment on or make changes to this bug.