exfat: add volume limit bounds checks#1320
Open
vfsci-bot[bot] wants to merge 3 commits intovfs.base.cifrom
Open
exfat: add volume limit bounds checks#1320vfsci-bot[bot] wants to merge 3 commits intovfs.base.cifrom
vfsci-bot[bot] wants to merge 3 commits intovfs.base.cifrom
Conversation
If the user inadvertenly truncates an exFAT volume(mistakenly shrinks the partition or simply dd'ing from a larger removable device to a smaller one. eg: device marketed as having 8GB capatity < 8GiB), the kernel exFAT obliviously mounts the volume and operates on it. No error is reported to userspace unless the filesystem is accessed with O_SYNC or O_DIRECT. Off by one sector test: # truncate -s 1073741824 img # mkfs.exfat img # truncate -s 1073741312 img # mount -t exfat img ... The existing filesystem implementations, prime examples being XFS and ext*, refuse to mount the volume with such condition. Introduce the checks similar checks in-place to exFAT. Also, to prevent UB, add checks against exFAT volumes with maliciously a crafted main boot sectors with the ClusterCount field equal to or larger than (2^32 - 11) as per format spec. Link: exfatprogs/exfatprogs#353 Signed-off-by: David Timber <[email protected]>
If the block size specified in the exFAT volume boot sector is different
from the actual logical block size of the device, many implementations
including FUSE-exfat, macos and previous versions of Windows are not
able to mount the volume.
A possible scenario in which this can happen is when the user dd's the
volume in a 4K-blocksize device("Advanced Format") to a 512-blocksize
device. This is a design issue inherent to the exFAT format itself
which layouts the structures of exFAT volumes aligned to the sector
size rather than large byte sizes as seen with other modern file
systems.
Print a kind warning about this potential compatibility issue.
Link: exfatprogs/exfatprogs#349
Signed-off-by: David Timber <[email protected]>
Fix memory leak conditions due to exfat_free_upcase_table() not being called. Signed-off-by: David Timber <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Series: https://patchwork.kernel.org/project/linux-fsdevel/list/?series=1089881
Submitter: David Timber
Version: 1
Patches: 3/3
Message-ID:
<[email protected]>Base: vfs.base.ci
Lore: https://lore.kernel.org/linux-fsdevel/[email protected]
Automated by ml2pr