Refactor the dirty flag handling a little bit so an inline function is called instead of directly stuffing a value into the variable. This allows variable that holds the flag to be completely removed if its not used i.e. CONFIG_FAT_WIRTE=n Signed-off-by: Daniel Palmer <daniel@thingy.jp>
The disk_read() and disk_write() functions of the FAT driver use the blk_dread() and blk_dwrite() respectively. The blk_* APIs read and write to the devices in terms of the device block size. However, the FAT driver reads in terms of the device block size (from fat_set_blk_dev and read_bootsectandvi) and sector size in the rest of the places. This causes buffer overflows or partial reads when the FAT sector size is not equal to device block size. Fix this by using blk_dread in fat_set_blk_dev and read_bootsectandvi instead of disk_read. And update disk_read/disk_write to handle FAT sector size and block size mismatch. Tested on blksz | FAT sector size ------+---------------- 4096 | 4096 512 | 512 4096 | 512 512 | 4096 Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
We do not perform a check on the value of getsize in get_fatent to ensure that it will fit within the allocated buffer. For safety sake, add a check now and if the value exceeds FATBUFBLOCKS use that value instead. While not currently actively exploitable, it was in the past so adding this check is worthwhile. This addresses CVE-2025-24857 and was originally reported by Harvey Phillips of Amazon Element55. Signed-off-by: Tom Rini <trini@konsulko.com>
This file references rtc functions and implicitly includes <rtc.h> today. Add this explicitly. Signed-off-by: Tom Rini <trini@konsulko.com>
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our Makefiles as part of the macros to determine when to do something in our Makefiles based on what phase of the build we are in. For consistency, bring this down to a single macro and use "$(PHASE_)" only. Signed-off-by: Tom Rini <trini@konsulko.com>
POSIX filesystem functions that create or remove directory entries contain text along the lines of "[function] shall mark for update the last data modification and last file status change timestamps of the parent directory of each file." [1][2][3] The common theme is these timestamp updates occur when a directory entry is added or removed. The create_link() and delete_dentry_link() functions have been changed to update the modification timestamp on the directory where the direntry change occurs. This differs slightly from Linux in the case of rename(), where Linux will not update `new_path`'s parent directory's timestamp if it is replacing an existing file. (via `vfat_add_entry` [4]) The timestamps are not updated if the build configuration does not support RTCs. This is an effort to minimize introducing erratic timestamps where they would go from [current date] -> 2000-01-01 (error timestamp in the FAT driver). I would assume an unchanged timestamp would be more valuable than a default timestamp in these cases. [1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/rename.html [2] https://pubs.opengroup.org/onlinepubs/9799919799/functions/unlink.html [3] https://pubs.opengroup.org/onlinepubs/9799919799/functions/open.html [4] https://elixir.bootlin.com/linux/v6.12.6/source/fs/fat/namei_vfat.c#L682 Signed-off-by: Gabriel Dalimonte <gabriel.dalimonte@gmail.com>
The implementation roughly follows the POSIX specification for rename() [1]. The ordering of operations attempting to minimize the chance for data loss in unexpected circumstances. The 'mv' command was implemented as a front end for the rename operation as that is what most users are likely familiar with in terms of behavior. The 'FAT_RENAME' Kconfig option was added to prevent code size increase on size-oriented builds like SPL. [1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/rename.html Signed-off-by: Gabriel Dalimonte <gabriel.dalimonte@gmail.com>
The create_link() code was previously duplicated in two existing functions. The two functions will be used in a future commit to achieve renaming. Signed-off-by: Gabriel Dalimonte <gabriel.dalimonte@gmail.com>
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is no-longer set. Signed-off-by: Simon Glass <sjg@chromium.org>
As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>