The ioctl operation used to configure a largepage shared memory object checks for an existing configuration without holding the necessary lock. This race condition allows two concurrent users to see an unconfigured object and set conflicting page sizes, leaving the object in an inconsistent state. The inconsistency can be exploited by an unprivileged local user to gain elevated privileges through manipulation of the shared memory mapping.

This flaw affects the FreeBSD implementation of POSIX shared memory, specifically the FIOSSHMLPGCNF ioctl defined in the kernel. No version range is given, so all FreeBSD releases that expose this ioctl without the lock fix are vulnerable until a patch is applied.

The vulnerability is local in nature: it requires an attacker to be able to invoke the ioctl from an unprivileged account on the same system. Because the race can be triggered by two concurrent operations, the exploitation requires precise timing but is otherwise straightforward for a local attacker. No EPSS or KEV score is available, and the CVSS score is not listed, however the potential for privilege escalation categorizes the risk as significant. Attackers should be aware that the absence of a lock may allow privilege escalation if the race is successfully triggered.