Some vulnerabilities tend to appear in independently written code. And CVE-2023-4273 isn’t an exception here…
A very similar vulnerability, CVE-2023-45897, has been discovered in the exfatprogs package: in particular, in the fsck tool. This vulnerability has exactly the same mechanics (even the same proof-of-concept file system image would work), but the overflow occurs in the heap memory, not in the stack.
Let’s compare the vulnerable code in the fsck tool of the exfatprogs package and in the kernel driver.
The fsck tool (my comments start with “//”):
for (i = 2; i <= file_de->file_num_ext; i++) { // 'file_de->file_num_ext' is attacker-controlled
ret = exfat_de_iter_get(iter, i, &dentry);
if (ret || dentry->type != EXFAT_NAME) {
if (i > 2 && repair_file_ask(iter, NULL, ER_DE_NAME,
"failed to get name dentry")) {
exfat_de_iter_get_dirty(iter, 0, &file_de);
file_de->file_num_ext = i - 1;
break;
}
*skip_dentries = i + 1;
goto skip_dset;
}
memcpy(node->name +
(i - 2) * ENTRY_NAME_MAX, dentry->name_unicode, // 'node->name' is 256 characters in length (heap-allocated)
sizeof(dentry->name_unicode));
}
/*
* First entry : file entry
* Second entry : stream-extension entry
* Third entry : first file-name entry
* So, the index of first file-name dentry should start from 2.
*/
for (i = ES_IDX_FIRST_FILENAME; i < es.num_entries; i++) { // 'es.num_entries' is attacker-controlled
struct exfat_dentry *ep = exfat_get_dentry_cached(&es, i);
/* end of name entry */
if (exfat_get_entry_type(ep) != TYPE_EXTEND)
break;
exfat_extract_uni_name(ep, uniname); // Append characters from 'ep' to 'uniname', which is 258 characters in length (stack-allocated)
uniname += EXFAT_FILE_NAME_LEN;
}
In both cases, there is no check that a concatenated file name doesn’t exceed 255 characters (this is the limit imposed by the file system specification). And on-disk exFAT structures are parsed in a way that allows the final file name to be much longer than the allocated string, leading to the overflow.
Two cases with different code, the same programming error, two vulnerabilities…
Timeline
- 2023-08-02: the vulnerability was discovered by me and then reported to the vendor.
- 2023-10-26: a fix is released.
- 2023-11-01: this post has arrived.
One thought on “CVE-2023-45897: a vulnerability in the Linux exFAT userspace tools”