CVE-2026-112908
Description
A flaw was found in filelock. When creating strict file locks on POSIX-compliant systems, coordination and claim directories are created without applying the caller's restrictive file permission settings. In environments with permissive file creation masks or default access control lists (ACLs), a local attacker can delete active lock claims or introduce invalid claim records into these directories. This can lead to unauthorized concurrent access to protected resources, potentially resulting in data corruption, or cause a denial of service (DoS) by preventing legitimate processes from acquiring locks.
Statement
This vulnerability is rated as Moderate impact because successful exploitation requires local unprivileged access alongside non-standard environmental configurations, such as an overly permissive umask or inherited default ACLs that grant write permissions to unauthorized users. On standard Red Hat Enterprise Linux deployments, the default system umask of 022 prevents arbitrary local users from deleting or modifying files within another user's lock directory. Consequently, unauthorized lock release, premature entry into critical sections, or denial-of-service conditions are restricted to shared multi-user setups with relaxed permission masks.
Mitigation
Configure processes that employ filelock to run with a restrictive umask (such as 022 or 027) and store lock files in dedicated, user-owned directories rather than shared world-writable directories such as /tmp. Additionally, verify that parent directories do not enforce default POSIX ACLs that grant write permissions to other users or groups.
To apply a restrictive umask to an application process or session:
bash
umask 027
To remove group and world write permissions on existing lock coordination trees:
bash
find /path/to/locks -maxdepth 2 -type d -name '*.filelock' -exec chmod -R go-w {} +
Enforcing restrictive umasks or removing write permissions will prevent legitimate cross-account lock sharing if an application intentionally relies on group-writable coordination files. Permission modifications should be executed while associated workloads are idle to avoid disrupting active synchronization.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 5.3 | N/A | 5.3 |
| Attack Vector | Local | N/A | Local |
| Attack Complexity | High | N/A | High |
| Privileges Required | Low | N/A | Low |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | None | N/A | None |
| Integrity Impact | High | N/A | High |
| Availability Impact | Low | N/A | Low |
Vector
Red Hat: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L
cve.org: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L
Understanding the Weakness (CWE)
Confidentiality,Integrity
Technical Impact: Read Application Data; Modify Application Data
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
