When the bitmap needs extending, 'vol->free_mft_records' is incremented
by 8*8=64 records. This is due to the bitmap's initialized area being
extended 8 bytes at a time.
However the way 'vol->free_mft_records' is being initialized is that all
the bits that are currently allocated to the MFT bitmap are already
taken into account at initialization time. This leads to a value for
'vol->free_mft_records' that is larger than the actual available number
of MFT records.
For example if there are 20 used MFT records and the bitmap has a 4096
byte allocation where 16 bytes are initialized, the number of free MFT
records are ((8 * 16) - 20) + (8 * (4096 - 16)) = 32748 records
available.
If we now expand the bitmap by 8 initialized bytes, we'd be adding 64
MFT entries according to the logic in the function
'ntfs_mft_bitmap_extend_initialized'.
However we are expanding it within the bounds of the existing allocation
where there is (4096 - 16) bytes free, so they shouldn't be added at all
at this stage.
The result is that our internal accounting is that we have 32748 + 64 =
32812 available MFT records, but in reality we will have 32748 records
available all the time until we expand the allocation beyond 4096 bytes.
Fixed by incrementing 'vol->free_mft_records' when the allocation is
expanded, not when the initialized size is.
When 'remove_reparse_index', called by 'ntfs_delete_reparse_index',
fails to look up a reparse key in the index, it leaves the
'ntfs_index_context' without a populated 'INDEX_BLOCK *ib' field.
This causes 'remove_reparse_index' to fail but the index entry is then
marked dirty unconditionally in 'ntfs_index_entry_mark_dirty', called by
'ntfs_delete_reparse_index', even though 'ib' may be NULL.
The following 'ntfs_index_ctx_put' call then starts to write out the
dirty 'INDEX_BLOCK', which causes a crash.
Fixed by only marking the index block dirty in if it's non-NULL.
Thanks to Stephen Greenham <sg@solarisfire.com> for reporting this issue
and providing debug information.
Runlists with no runs are tolerated though not expected. However merging
such runlists is problematic as there is no significant vcn to examine.
So avoid merging them, and just return the other runlist.
A zero-size run is the universal way to indentify the end of a runlist,
so we must reject zero-sized runs when decompressing a runlist. A
zero-size data run is an error, and a zero-size hole is simply ignored.
When copying an attribute name which contains a null, it is truncated
and this may lead to accessing non-allocated bytes when relying on the
expected name length. Such (illegal) names must therefore be rejected.
Before reading a full attribute value for internal use, its expected
length has been checked to be < 0x40000. However the allocated size
in the runlist may be much bigger as a consequence of a bug or malice.
To prevent malloc'ing excessive size, restrict the size of the last
run to read to the needed length.
When copying an attribute name which contains a null, it is truncated
and this may lead to accessing non-allocated bytes when relying on the
expected name length. Such names must therefore be rejected.
When creating a new MFT record, the former seq_no and usn are retrieved
to avoid the new one to be mistaken for the former one.
This may not be possible when the record is used for the first time
or after some bad error. In such situation use default values.
The recent detection of a truncated attribute list entry overlooked the
normal detection of the end of list. Moreover the check for name
overflow is to be done later and not needed at this stage.
Allocating clusters to the main bitmap may imply updating the bitmap
itself within a cluster not yet allocated. This can turn into endless
recursions and has to be rejected. Currently the bitmap is assumed
to be fully allocated.
The count of free clusters may be updated while mounting before it
has been initialized, which may lead to irrelevant error messages.
Moreover the count is not computed at all in some ntfsprogs utilities.
So set up a flags to avoid outputting irrelevant errors.
Make sure the used part of an index block fits into the allocated buffer.
Note : a negative size may cause overflow on 32-bit cpus.
(contributed by Rakesh Pandit)
The standard size is 2560 bytes. It can be extended for specific purposes,
but its former limit to 32 bits was unreasonable. Anyway ntfs-3g is
not committed to support non-standard situations.
Checked that attributes are [non-]resident when they have to be, and
grouped consistency checks on each of them in a dedicated function.
Consequenly request the checks where needed and remove existing index
checks.
The standard information of the MFT must be its first attribute in the
base record. If it is not accessible initially, we end up searching it
in an extent before the MFT struct is ready for that.
The end of the attributes must be checked against the space in use
rather than the allocated space. This contributes to the safety of
subsequent attribute resizing.
Make sure the attribute designated to readall() has a reasonable size.
Apart from a bitmap, in a valid call, the attribute size is limited to
65536, and bitmaps are limited by the number of cluster.
When appending to an existing compressed file, the last block must first
be decompressed. When doing so, clear the tail of buffer in order to not
leak unrelated data.
Reject updating uninitialized MFTMirr because it leads to endless
recursions as updating the MFTMirr entry of MFT implies further updating
MFTMirr.
This is probably specific to ntfsfix, as mounts are normally rejected
when MFTMirr does not match MFT.
Make sure the attributes fully lie within the MFT record, and make sure
their variable components (name, runlist, value) fully lie within the
attribute.
The consistency check on the upcase size was laxist.
The unicode points are limited to 1048575 (20 bits), but there is no
provision to support code points beyond 65535.
In the current implementation the upcase size must be even and <= 131072.
Erik Larsson
Jean-Pierre André
Jean-Pierre André