From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8154 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?Q?Lo=EFc_Runarvot?= Newsgroups: gmane.linux.lib.musl.general Subject: Left-shift of negative number Date: Fri, 17 Jul 2015 18:28:00 +0000 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_a0649adad5fc4c04b9616443ce18326aS1688EX1688lan_" X-Trace: ger.gmane.org 1437157706 25735 80.91.229.3 (17 Jul 2015 18:28:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Jul 2015 18:28:26 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-8167-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 17 20:28:13 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZGAMm-0006mc-O6 for gllmg-musl@m.gmane.org; Fri, 17 Jul 2015 20:28:12 +0200 Original-Received: (qmail 25909 invoked by uid 550); 17 Jul 2015 18:28:05 -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 25813 invoked from network); 17 Jul 2015 18:27:58 -0000 Thread-Topic: Left-shift of negative number Thread-Index: AQHQwL5P62KicAzZW0uAcLUCqvyDqA== Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [84.14.219.2] Xref: news.gmane.org gmane.linux.lib.musl.general:8154 Archived-At: --_000_a0649adad5fc4c04b9616443ce18326aS1688EX1688lan_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable According to the C11 standard, doing a left-shift on a negative integer is = considered as an undefined behavior (6.5.7:4). This undefined behavior occurs in files src/multibyte/internal.c and src/mu= ltibyte/internal.h. At line 21 in the header (http://git.musl-libc.org/cgit/musl/tree/src/multi= byte/internal.h?id=3D0f9c2666aca95eb98eb0ef4f4d8d1473c8ce3fa0#n21), the implementation of the macro-definition R allow to have a negative value= on the expression ((a =3D=3D 0x80) ? 0x40-b : -a) << 23. In fact, in the source file, at the line 11 (http://git.musl-libc.org/cgit/= musl/tree/src/multibyte/internal.c?id=3D0f9c2666aca95eb98eb0ef4f4d8d1473c8c= e3fa0#n11). During the application of the macro-definition R(0x90, 0xc0), we have a != =3D 0x90, so it's try to do (-0x90) << 23, which is an undefined behavior. This bug was found in the context of the libc cross-testing project (a post= blog has been written on this subject yesterday: http://trust-in-soft.com/= the-libc-cross-testing-project) --_000_a0649adad5fc4c04b9616443ce18326aS1688EX1688lan_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

According to the C11 standard, doing = a left-shift on a negative integer is considered as an undefined behavior (= 6.5.7:4).

This undefined behavior occurs in files src/multibyte/internal.c and s= rc/multibyte/internal.h.
At line 21 in the header (http://git.musl-libc.org/cgit/musl/tree/src/= multibyte/internal.h?id=3D0f9c2666aca95eb98eb0ef4f4d8d1473c8ce3fa0#n21),
the implementation of the macro-definition R allow to have a negative = value on the expression ((a =3D=3D 0x80) ? 0x40-b : -a) << 23.

In fact, in the source file, at the line 11 (http://git.musl-libc.org/= cgit/musl/tree/src/multibyte/internal.c?id=3D0f9c2666aca95eb98eb0ef4f4d8d14= 73c8ce3fa0#n11).
During the application of the macro-definition R(0x90, 0xc0), we have = a !=3D 0x90, so it's try to do (-0x90) << 23, which is an undefined b= ehavior.

This bug was found in the context of the libc cross-testing project (a= post blog has been written on this subject yesterday: http://trust-in-soft= .com/the-libc-cross-testing-project)

--_000_a0649adad5fc4c04b9616443ce18326aS1688EX1688lan_--