CVE-2024-42318
landlock: Don't lose track of restrictions on cred_transfer
- State
- Published
- Severity
- 8.8 High
- Published
- Aug 17, 2024
- Updated
- Aug 5, 2026
- Reserved
- Jul 30, 2024
Description
In the Linux kernel, the following vulnerability has been resolved:
landlock: Don't lose track of restrictions on cred_transfer
When a process' cred struct is replaced, this _almost_ always invokes the cred_prepare LSM hook; but in one special case (when KEYCTL_SESSION_TO_PARENT updates the parent's credentials), the cred_transfer LSM hook is used instead. Landlock only implements the cred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causes all information on Landlock restrictions to be lost.
This basically means that a process with the ability to use the fork() and keyctl() syscalls can get rid of all Landlock restrictions on itself.
Fix it by adding a cred_transfer hook that does the same thing as the existing cred_prepare hook. (Implemented by having hook_cred_prepare() call hook_cred_transfer() so that the two functions are less likely to accidentally diverge in the future.)
Scores
| CVSS | Score | Vector | Source |
|---|---|---|---|
| 3.1 | 8.8 High | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H | Linux |
Weaknesses
The record names no weakness.
Affected Products
| Product | Versions |
|---|---|
LinuxLinux |
|
LinuxLinux |
|
References
- https://git.kernel.org/stable/c/916c648323fa53b89eedb34a0988ddaf01406117
- https://git.kernel.org/stable/c/0d74fd54db0bd0c0c224bef0da8fc95ea9c9f36c
- https://git.kernel.org/stable/c/16896914bace82d7811c62f3b6d5320132384f49
- https://git.kernel.org/stable/c/b14cc2cf313bd29056fadbc8ecd7f957cf5791ff
- https://git.kernel.org/stable/c/39705a6c29f8a2b93cf5b99528a55366c50014d1
- https://lore.kernel.org/all/20240817.shahka3Ee1iy@digikod.net/
- https://www.openwall.com/lists/oss-security/2024/08/17/2
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2566
- http://www.openwall.com/lists/oss-security/2024/08/17/2
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.