In the Linux kernel, the following vulnerability has been resolved:

f2fs: bound iinlinexattrsize for non-inline-xattr inodes

When the flexibleinlinexattr feature is enabled, doreadinode() loads the on-disk iinlinexattrsize unconditionally:

if (f2fssbhasflexibleinlinexattr(sbi)) fi->iinlinexattrsize = le16tocpu(ri->iinlinexattrsize);

but sanitycheckinode() only range-checks it when the inode also has the FIINLINEXATTR flag set. An inode that carries an inline dentry or inline data but not FIINLINEXATTR -- the normal layout for an inline directory -- therefore keeps a fully attacker-controlled iinlinexattrsize from a crafted image.

getinlinexattraddrs() returns that value with no flag gating, so it feeds the inode geometry:

MAXINLINEDATA() = 4 (CURADDRSPERINODE - iinlinexattrsize - 1) NRINLINEDENTRY() = MAXINLINEDATA() BITSPERBYTE / (...) addrsperpage() = CURADDRSPERINODE - iinlinexattrsize

A large iinlinexattrsize drives MAXINLINEDATA() and NRINLINEDENTRY() negative, so makedentryptrinline() sets d->max (int) to a negative value. The inline directory walk then compares an unsigned long bitpos against that negative d->max, which is promoted to a huge unsigned bound, and reads far past the inline area:

while (bitpos < d->max) / fs/f2fs/dir.c / ... testbitle(bitpos, d->bitmap) / d->dentry[bitpos] ...

Mounting a crafted image and reading such a directory triggers an out-of-bounds read in f2fsfilldentries(); the same underflow also corrupts ADDRSPERINODE for regular files.

Validate iinlinexattrsize against MAXINLINEXATTRSIZE whenever the flexibleinlinexattr feature is enabled -- i.e. whenever the value is loaded from disk and consumed -- and keep the lower MININLINEXATTRSIZE bound gated on inodes that actually carry an inline xattr, so legitimate inodes with iinlinexattrsize == 0 are still accepted.