In the e2fsck utility included with the package , (), allows an attacker to execute code during the file system check of directories that are specially crafted. The vulnerability has been confirmed in versions from 1.43.3 to 1.45.4. The vulnerability has been fixed in the update . In the distributions, the issue remains unresolved (, , , , ).
The vulnerability is caused by a flaw in the mutate_name() function from the rehash.c file, which is used when reconstructing hash tables related to directories that map all files within them. Corruption of the directory-related hash_entry structure may allow an attacker to write data outside the allocated buffer. When multiple files with the same name are found in the directory's hash table, the e2fsck utility renames the duplicate files by appending ~0, ~1, etc., to their names. For temporarily storing the new name during such renaming, a buffer of size 256 bytes is allocated on the stack.
The size of the data being copied is determined by the expression "entry->name_len & 0xff", but the value of entry->name_len is loaded from the structure on disk rather than being computed based on the actual size of the name. If the size is zero, the array index takes the value -1, creating conditions for integer underflow and overwriting other stack data with the value "~0". For 64-bit systems, exploitation of the vulnerability is considered unlikely and requires having no stack size limits (ulimit -s unlimited). For 32-bit systems, exploitation is considered possible, but the outcome largely depends on how the executable was compiled.
To carry out an attack, an attacker needs to corrupt data in a section with an ext2, ext3, or ext4 file system. Since this operation requires superuser privileges, the vulnerability poses a threat when the e2fsck utility checks external drives or filesystem images obtained from external sources.
Source: opennet.ru
