[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andreas Dilger
Subject: Re: [Bug-tar] [PATCH] fix overflow in code_ns_fraction()
Date: Fri, 05 Feb 2010 09:54:02 -0700

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]