Bugzilla – Bug 1193997
VUL-0: CVE-2022-23948: keylime: check_mounted secure mount logic can be fooled by unprivileged mounts
Last modified: 2022-02-18 09:52:33 UTC
This is to keep track of the keylime review issue 2 a):
### a) `check_mounted()` Function Logic can be Fooled by Unprivileged
The `check_mounted()` function in `secure_mount.py` attempts to make sure
that a "secure" tmpfs is mounted at `/var/lib/keylime/secure` to store
data on that never gets written to disk. To do so the function parses the
output of the `mount` utility to determine whether this file system is
mounted at the desired location.
There can exist the possibility of unprivileged users performing certain
operations, one of the most prominent examples being the `fusermount`
setuid-root binary for mounting FUSE file systems. In view of this parsing
mount table output needs prudence. I described the basic issue previously
already in another report .
The following is a reproducer using `fusermount` that shows the basic local
user$ export _FUSE_COMMFD=0
user$ fusermount some/path/ -ononempty,fsname="tmpfs on
This will fool the parsing logic in `check_mounted()` and thus the function
assumes that the "secure" tmpfs is already mounted, while it actually
Thus this will allow a local attacker on the system to prevent this
feature to be effective, *if* the local attacker manages to create such a
entry before the `keylime_agent` runs.
The attack vector can also be used to perform a local DoS against
`keylime_agent` by claiming a different `fsname` than tmpfs.
will throw an Exception in this case and the agent won't start.
On a side note there are calls to `secure_mount.mount()` spread throughout
Keylime codebase (for example three times in `keylime_agent.py`, two times
`tpm_main.py` and two times in `ca_impl_cfssl.py`. There is no code to
up* this mount again, however. So it potentially leaves behind a stale
after services are shutdown. Furthermore if multiple Keylime processes
operate in parallel this could result in a race condition where the
tmpfs is mounted twice, in the worst case mounting a fresh tmpfs over
previously stored content there.
My recommendation is to parse the `/proc/self/mountinfo` pseudo file for
table information instead. Whitespace is specially encoded in this file.
Furthermore the responsibility of mounting and unmounting this file system
should be more clearly defined during startup/shutdown of processes and
a reference counting / locking scheme to prevent race conditions should be
The issue has been confirmed by upstream and CVE-2022-23948 has been assigned.
the issue is public now via the following security advisory:
Fixed in version 6.3.0 and both SLE-15-SP4 and Factory are updated.