ntfsrecover -f -v <log file> receives a SIGSEGV because of trying to
read memory outside allocated buffer because of no sanity checks on
restart page header values. This happens on an empty $LogFile because
of no basic checks present. Attached patch adds basic checks similar
to those inside logfile library and allows tool to exit with more
suitable message.
(contributed by Rakesh Pandit)
These tools were originally developed for running on Windows and later
ported to libntfs-3g. This patch makes them similar to other ntfsprogs
tools, dropping the native Windows interfaces and using libntfs-3g on
all platforms.
There is no change in usage or supported features, only the command
names have changed.
These tools were developped before the ntfsprogs were merged into ntfs-3g,
redesigning them like the ntfsprogs make the code simpler.
Note : at this stage secaudit and usermap cannot be built any more.
Prepare merging ntfsrecover.h into logfile.h by adding a usn field to
RESTART_PAGE_HEADER. As this changes the record size, ignore the new
field in existing code.
Usually, only a few pages of the Windows log file are saved in an
ntfsclone image. This is inappropriate for building reference images
for recovering the log, and the --full-logfile option serves that
purpose.
When an INDX or MFT record could not be read while undoing the creation
of this record, there is nothing to do. However if this was undoing the
deletion of the last entry in an index, a new void index block has to be
created.
The previous fix for the warning referred to 'prevbuf' being used
uninitialized and this is also what the compiler says. However
initializing 'prevbuf' doesn't make the warning go away and further
testing revealed that it is really 'savebuf' being possibly used prior
to initialization that is the source of the warning (the incorrect
warning message is probably an optimization-related gcc bug). So replace
previous ineffective fix with explicit initialization of 'savebuf'.
For 64-bit (e.g. x86_64) Linux the 64-bit wide types resolve to long,
not long long as is the case in 32-bit (e.g. i386) Linux. So we need an
explicit cast to long long for 64-bit types since the format string must
specify the 'll' modifier in order to print 64-bit values.
Some compilers issue a warning when a pointer is initialized in
both alternatives of a condition. Force an extra initialization
to avoid such warnings.
Closing the volume is the way to sync the MFT to disk. When not doing
so, the MFT runlists in $DATA and $Bitmap are not synced if they have
been updated in the second resizing stage relative to runlists which
have grown outside their original MFT record.
Unlike in most cases, the bad sector inode has to be closed if it
was updated and required MFT extents (when there are a lot of bad
sectors and some of them were outside the truncated partition).
Not doing so causes the inode to not be fully synced to device.
The UTF-16LE label buffer containing the result of mbs2ucs is the one
that should be NULL-terminated when the label is longer than permitted.
Not the input buffer, which is a function parameter assumed to be
NULL-terminated anyway.
This is done to match the type of the LSN struct members in layout.h.
The effect of this change is that while these members were declared with
the le64 type previously, leLSN resolves to sle64. I.e. what was
previously unsigned fields are now signed.
Following this change we also need to switch over a few macros from
unsigned to signed versions in the code that uses these struct
definitions.
There were multiple cases of little-endian fields being used as
CPU-endian without byte swapping. This would result in incorrect
behaviour on big-endian systems.
On big-endian systems the result of the '!=' operation would be
endian-swapped rather than the first argument (which must have been the
intended action).
This is harmless except when we do strict endianness checking, in which
case this results in a compile error. Fixed by converting values to
CPU endianness before comparing them.
In 'dump_resident_attr_val', 'i' was sometimes used as a native-endian
'int'-precision string length value and sometimes used as a little-
endian 16-bit flags value. This type of mixed usage is bad practice and
results in a hard error when strict endianness checking is used.
Fixed by introducing new variable 'flags' to hold the little-endian 16-
bit flags value.
If the attribute type is specified by the user, 'attr_type' was assigned
a CPU-endian value, however if the attribute type was not specified it
would be assigned the attribute type AT_DATA, which is a little-endian
value. The rest of the code seems to assume that 'attr_type' is
CPU-endian, so this is clearly a bug.
Resolved by fixing the endianness of the variable at little-endian,
converting the input value to little-endian when specified.
In 'dump_attr_record' the variable 'u' was first used to store a
CPU-endian 32-bit value, and then to store a 16-bit little-endian value.
This is bad practice and results in a hard error when strict endian type
checking is used.
Fixed by storing the 16-bit little-endian flags value in a new variable
'flags'.
This commit addresses issues where little-endian variables are emitted
raw to a log or output stream which is to be interpreted by the user.
Outputting data in non-native endianness can cause confusion for anybody
attempting to debug issues with a file system.
