From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6187 Path: news.gmane.org!not-for-mail From: Jens Gustedt Newsgroups: gmane.linux.lib.musl.general Subject: [PATCH v2] fix a bug in the rand48 family of prng Date: Mon, 22 Sep 2014 15:41:10 +0200 Message-ID: <1411393197.4884.241.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------1.9.1" X-Trace: ger.gmane.org 1411393280 19537 80.91.229.3 (22 Sep 2014 13:41:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Sep 2014 13:41:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6200-gllmg-musl=m.gmane.org@lists.openwall.com Mon Sep 22 15:41:13 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XW3rb-0001NP-I2 for gllmg-musl@plane.gmane.org; Mon, 22 Sep 2014 15:41:11 +0200 Original-Received: (qmail 28388 invoked by uid 550); 22 Sep 2014 13:41:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 28377 invoked from network); 22 Sep 2014 13:41:09 -0000 X-IronPort-AV: E=Sophos;i="5.04,571,1406584800"; d="scan'208";a="97208238" Resent-From: Jens Gustedt Resent-To: musl@lists.openwall.com X-Mailer: Evolution 3.4.4-3 Xref: news.gmane.org gmane.linux.lib.musl.general:6187 Archived-At: This is a multi-part message in MIME format. --------------1.9.1 Content-Type: text/plain; charset=UTF-8; format=fixed Content-Transfer-Encoding: 7bit This fixes a bug found by Nadav Har'El, who observed that musl was giving different prn sequences than other systems, even if seeded with the same value. The problem with something like a = lc[0] | lc[1]<<16 | lc[2]+0ULL<<32; where lc[1] is an unsigned short and int is 32bit is the following (1) lc[1] is promoted to int (2) the left shift 16 is performed on int this is UB if bit 15 is set in lc[1], since it moves a 1 into the sign bit. In particular, bit 15 *is* 1 for the default multplicator A as defined by POSIX. (On systems with 16 bit int all of this has UB anyhow.) If the platform defines the behavior (most do) we are still not saved. Then we have an bit-or between an int and an ullong. If the int is negative sign extension sets all the high bits of the result, messing up the computation completely. --- src/prng/__rand48_step.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --------------1.9.1 Content-Type: text/x-patch; name="0001-fix-a-bug-in-the-rand48-family-of-prng.patch" Content-Disposition: inline; filename="0001-fix-a-bug-in-the-rand48-family-of-prng.patch" Content-Transfer-Encoding: 7bit diff --git a/src/prng/__rand48_step.c b/src/prng/__rand48_step.c index ccaffc3..961d30f 100644 --- a/src/prng/__rand48_step.c +++ b/src/prng/__rand48_step.c @@ -3,8 +3,8 @@ uint64_t __rand48_step(unsigned short *xi, unsigned short *lc) { uint64_t a, x; - x = xi[0] | xi[1]<<16 | xi[2]+0ULL<<32; - a = lc[0] | lc[1]<<16 | lc[2]+0ULL<<32; + x = xi[0] | xi[1]+0U<<16 | xi[2]+0ULL<<32; + a = lc[0] | lc[1]+0U<<16 | lc[2]+0ULL<<32; x = a*x + lc[3]; xi[0] = x; xi[1] = x>>16; --------------1.9.1--