Re: [Bug-tar] [PATCH] fix overflow in code_ns_fraction()

[Andreas Dilger]

On 2010-02-05, at 02:42, Kamil Dudka wrote:
> On Friday 05 of February 2010 09:48:00 Andreas Dilger wrote:
> > If the on-disk nanoseconds count happens to exceed 999,999,999 then
> > code_ns_fraction() will overflow the 9-character array and segfault.
> > While this shouldn't happen normally, it can happen due to corruption
> > of the on-disk data.  If the ns field is larger than 999,999,999
> > truncate it to this value
>
> thanks for bringing the patch here.  I am attaching our version of  
> the same
> patch.  It tries to count the overflowed ns into the second part and  
> ignores
> any negative value of ns, which can cause SIGSEGV as well.  In fact  
> I am not
> sure if such a situation can really happen, tested only with a  
> debugger.


I would argue that any nanosecond value >= 10^9 is simply due to  
corruption, and  propagating that into the seconds field isn't really  
helping anything.  However, I agree that it should also check for ns <  
0 and clamp this to 0, since the timespec.ns or timeval.us field are  
normally "long" and could theoretically be negative if the on-disk  
value is corrupted and the kernel/filesystem doesn't validate the  
values.

It is probably worthwhile to have e2fsck et. al. check for and fix  
such corruption, but there are already filesystems in the wild with  
these bad timestamps and tar shouldn't segfault when backing them up.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.