CVE-2024-53147

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

Triggering requires a crafted exFAT image to be mounted and then a lookup/create performed in the corrupt directory, which is a local operation — an unprivileged desktop user can loop-mount an arbitrary image via udisks2, or operate on an automounted USB/SD card. There is no network-reachable path into fs/exfat.

AC:LAttack complexity, low

The attacker fully controls the on-disk bytes: setting a directory's stream-extension dentry to size >= cluster_size with an invalid start_clu is deterministic, and the follow-up lookup+create is a plain syscall sequence with no race, timing, or memory-layout dependency.

PR:LPrivileges required, low

Only ordinary local user privileges are needed — udisks2/automount lets an unprivileged session user get the crafted exFAT image mounted, and any low-privileged user can then run lookup/creat/mkdir in the corrupt directory to drive the out-of-bounds access. Real root in the init namespace is not required.

UI:NUser interaction, none

In the self-mount scenario the attacker performs every step themselves — mount the image via the automount/loop path, then issue the lookup and create — with no action by any other user required.

S:UScope, unchanged

The corruption and disclosure stay within the kernel's own security authority and the filesystem it manages; no VM, IOMMU, or sandbox boundary is crossed.

C:HConfidentiality impact, high

Because hint_femp.eidx and the inflated directory size index clusters outside the directory, readdir/lookup read clusters belonging to other files — or arbitrary sectors of the device with the unvalidated `cur_clu += clu_offset` path — and hand that content back to userspace as directory-entry names and attributes.

I:HIntegrity impact, high

Directory entries are written into clusters owned by other files, and exfat_chain_cont_cluster() rewrites FAT entries for clusters it does not own, splicing another file's clusters into the corrupt directory; this destroys unrelated user data and filesystem metadata, exactly the "further file system corruption" the commit cites.

A:HAvailability impact, high

The bogus accesses funnel into exfat_fs_error(), which calls panic() under the supported errors=panic mount option and forces the filesystem read-only under the default, and the resulting inconsistent inode (i_size claiming N+1 clusters over a one-cluster chain) yields repeated I/O failures on every subsequent operation.