UBUNTU-CVE-2026-89839: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: f2fs: use the mount idmap for the owner check in f2fsxattradviseset() f2fsxattradviseset() calls inodeownerorcapable() with &nopmntidmap before allowing the "system.advise" xattr to be set, instead of the idmap that the VFS passes to the ->set() handler. f2fs supports idmapped mounts, so on such a mount this checks the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EPERM and an unrelated caller wrongly allowed. Pass the handler's idmap instead.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue affects the listed Ubuntu Linux kernel packages when F2FS is used through an idmapped mount. Systems that do not use F2FS idmapped mounts are not described as affected by this ownership-check mismatch.
What must an attacker or unauthorized user be able to do to exploit it?
They need to interact with an F2FS filesystem mounted with an idmap and attempt to set the system.advise extended attribute. The flaw can cause the ownership check to authorize an unrelated caller or deny the actual mapped owner.
What is the impact of successful exploitation?
An unrelated caller may be incorrectly permitted to set the system.advise xattr on an inode due to ownership being checked against the unmapped on-disk owner. Conversely, the actual owner may receive an EPERM error.
What should be done if the updated kernel cannot be deployed immediately?
Avoid using idmapped mounts with F2FS where possible, especially where untrusted or differently mapped users can set extended attributes. This removes the specific mount-identity mapping condition described for the flaw.