CVE-2026-63814

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

The bug is reached through local kernel entry points—`getxattr`/`listxattr` syscalls (`path_getxattrat` → `do_getxattr` → `do_get_acl` → `vfs_get_acl` → `__get_acl` → `f2fs_get_acl` → `f2fs_acl_from_disk`), routine VFS permission checks (`check_acl` → `get_inode_acl`), and f2fs inode creation (`f2fs_init_acl` → `__f2fs_get_acl`). f2fs is overwhelmingly deployed as a local block filesystem (Android userdata, embedded flash); although nfsd/ksmbd also call `get_inode_acl`, that is a secondary path.

AC:LAttack complexity, low

Once a malformed on-disk ACL xattr exists, triggering is deterministic—the attacker fully controls the crafted ACL blob layout that passes `f2fs_acl_count()` but places `ACL_USER`/`ACL_GROUP` in a short-entry slot, causing a reliable 4-byte read past the allocated buffer. No races or victim-specific timing are required.

PR:LPrivileges required, low

Normal `setxattr`/`setfacl` paths validate through `posix_acl_from_xattr` and write via `f2fs_acl_to_disk`, so planting the malformed on-disk format requires offline image crafting plus `CAP_SYS_ADMIN` (obtainable in an unprivileged user namespace) to loop-mount the image, or real root for raw block-device writes. Triggering only needs read access to the affected inode; `vfs_get_acl` performs no xattr permission check beyond LSM hooks.

UI:NUser interaction, none

In the highest-impact self-contained attack, the attacker crafts a malicious f2fs image and mounts it inside their own user namespace—no victim interaction is required. A USB-delivery variant would need the victim to mount media, but that is not necessary for exploitation.

S:UScope, unchanged

The out-of-bounds read corrupts/leaks kernel heap memory within the same kernel security domain. This is a standard local kernel memory-safety flaw, not a cross-boundary escape (VM, container, or IOMMU).

C:HConfidentiality impact, high

The vulnerability is a slab out-of-bounds read (`entry->e_id`, 4 bytes) past the kmalloc'd ACL xattr buffer when a truncated `ACL_USER`/`ACL_GROUP` entry is parsed. This reads adjacent kernel heap objects and can disclose kernel pointers or other sensitive kernel data, satisfying the guidance for out-of-bounds kernel reads.

I:HIntegrity impact, high

Although the immediate fault is a read past bounds rather than a write, this is kernel heap memory corruption class behavior; adjacent-slab reads are routinely chained into further kernel exploitation (heap grooming, control of subsequent allocations) for arbitrary write and code execution. Per the scoring guidance to treat memory corruption bugs as enabling integrity compromise when uncertain, I:H is appropriate.

A:HAvailability impact, high

The KASAN report confirms a slab-out-of-bounds access in `__f2fs_get_acl` during a syscall. The same path is hit on every permission-checked file access (`open`, `stat`, `exec`) and directory inode creation, so a malicious ACL on a widely accessed file can repeatedly fault the kernel or destabilize the system under memory hardening.