[sleuthkit-developers] [ sleuthkit-Bugs-3052302 ] segfault in UFS1 file system with corrupt inodes.

[SourceForge.net <no...@so...>]

Bugs item #3052302, was opened at 2010-08-24 08:56
Message generated for change (Settings changed) made by carrier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3052302&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: File System Tools
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Rob J Meijer (ghede)
Assigned to: Brian Carrier (carrier)
Summary: segfault in UFS1 file system with corrupt inodes. 

Initial Comment:
When processing inode 10240 of the ufs filesystem on the partition-3 image of the ntfs-auto-detect images in the dftt testset, a segfault occurs.
Using fls the segfault can be reproduces:

fls -f ufs 10-ntfs-part3.dd 10240



----------------------------------------------------------------------

>Comment By: Brian Carrier (carrier)
Date: 2010-09-18 09:05

Message:
Further investigation shows that the corrupt inode was created by the
overlapping NTFS file system.  The inode table for this cyl group starts in
block 20120 and the UFS file system has a 2K block size. That maps to
sector 80480. On the NTFS side of the house, that maps to the $UpCase (MFT
entry 10) file. 

The crash occurred because of a little bug in tsk_malloc where it tried to
memset even if the malloc failed...

Fixed:
Sending        trunk/NEWS.txt
Sending        trunk/tsk3/base/mymalloc.c
Transmitting file data ..
Committed revision 256.

----------------------------------------------------------------------

Comment By: Rob J Meijer (ghede)
Date: 2010-08-25 02:56

Message:
The versions I've tested this bug exists are 3.1.1 and 3.1.3.



----------------------------------------------------------------------

Comment By: Brian Carrier (carrier)
Date: 2010-08-24 20:44

Message:
The problem actually appears to be with inode 5296.  It has a massive size
and what appears to be a lot of invalid metadata.  perhaps this inode was
not initialized.  UFS2 has a feature of not initializing inodes, perhaps
UFS1 does as well. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3052302&group_id=55685