Re: [sleuthkit-developers] sleuthkit bug in fs_data.c

[Brian C. <ca...@sl...>]

David Collett wrote:
> Hi Brian,
> 
> On Fri, Nov 17, 2006 at 05:13:28PM -0500, Brian Carrier wrote:
>> Indeed you are correct.  I just fixed it (the next version will 
>> hopefully be out next week once I track down an elusive NTFS compression 
>> bug).
> 
> I think I've seen this too, on friday afternoon, I didnt get much time
> to look into it. glibc detecting a double free in ntfs_uncompress_done??
> 
> Let me know this week if you want me to test your solution.

My initial fix for this problem turned into an infinite loop.  It 
appears to happen when the file is unallocated and the clusters 
allocated to the file have been reused.  The new data screws up the 
compression algorithm somehow...  If you have a file that causes that 
message though, I could use your help debugging this.


>> Where else did you see this issue?  I think fs_data is the only 
>> structure that is reused.
> 
> If you grep the sources in src/fstools for FS_DATA_INUSE, you will see a few
> more while loops with the same structure e.g.:
> 
> ...
> dcalc_lib.c:151:        while ((fs_data) && (fs_data->flags & FS_DATA_INUSE)) {
> dls_lib.c:178:  while ((fs_data) && (fs_data->flags & FS_DATA_INUSE)) {
> fls_lib.c:137:      while ((fs_data) && (fs_data->flags & FS_DATA_INUSE)) {
> ...
> (there are more)

Oh, I get it now.  I thought you meant there were other structures that 
had a similar design problem.  I think I will both update the loops and 
update the _alloc methods so that the used attributes are moved to the 
head of the list.

thanks,
brian