lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20071107152833.6f302c2a.akpm@linux-foundation.org>
Date:	Wed, 7 Nov 2007 15:28:33 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	David Brown <lkml@...idb.org>
Cc:	linux-kernel@...r.kernel.org, Ulrich Drepper <drepper@...hat.com>,
	Michael Kerrisk <mtk-manpages@....net>
Subject: Re: compat_sys_times() bogus until jiffies >= 0.

> On Wed, 7 Nov 2007 14:47:22 -0800 David Brown <lkml@...idb.org> wrote:
> compat_sys_times() has bogus return until jiffies is >= 0.  I discovered
> this running LTP within 5 minutes of booting.
> 
> The return result
> 
> 	return compat_jiffies_to_clock_t(jiffies);
> 
> will return '-1' to user space and set the negated clock_t value to errno.
> 
> I'm not sure what the correct fix for this is.  I can come up with a patch
> if anyone has ideas on how to fix it.
> 
> At minimum, perhaps it should return a sane errno value.

RETURN VALUE
       times()  returns  the  number of clock ticks that have elapsed since an
       arbitrary point in the past.  For Linux 2.4 and earlier this  point  is
       the  moment  the  system  was  booted.   Since Linux 2.6, this point is
       (2^32/HZ) - 300 (i.e., about 429 million) seconds  before  system  boot
       time.   The  return  value  may  overflow  the  possible  range of type
       clock_t.  On error, (clock_t) -1 is returned, and errno is  set  appro-
       priately.


Perhaps this is a bug in glibc: it is interpreting the times() return value
in the same way as other syscalls.

It would have been sensible for us to add INITIAL_JIFFIES to the value
instead of exposing this kernel-only detail to the world, although the
problem will of course reoccur once jiffies hits 0x80000000.  Unfortunately
we've even gone and enshrined this bogon in the manpage.

Proposed fix:

-        return compat_jiffies_to_clock_t(jiffies);
+        return compat_jiffies_to_clock_t((jiffies + INITIAL_JIFFIES) &
+						0x7fffffff);

?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ