From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 26073 invoked from network); 30 Apr 2020 20:31:43 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 30 Apr 2020 20:31:43 -0000 Received: (qmail 20316 invoked by uid 550); 30 Apr 2020 20:31:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 20286 invoked from network); 30 Apr 2020 20:31:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=1nic5ktiL0oztkEvHkl1TZtOKVIxBnVja4N+ELXzV0s=; b=VGKhNCZb36+MvhhEDrWQMHqYVlftAIOdTZFPqUOcuG4MUp4Bpj8Rq28ta1Op9nY5Ts xx9w7HHSPG9XlU8wrwHthr7+cwTLxvBzoiS5LghB65BhiqzpNxqFFdAXIj1CQH299Lpr ta43jL+8Dj5P2g8+2cKMF6LZ4O/sbf9ye/1cxFinJAj+GmCNwuqUKCTM6LHeqz5YfbX4 fuOCUEk0h8+k3Apfkm+qiRA4KAgMmHI1vbgAwUNq8YOGlJrHaT61t/aICZQhOUKXZ3jx /xAO78juvKHEyY4JBUtpLQN5EMjdwk6jz3sm+Xx03R3s7FKprvIiR92FRIO9KJYlxCrE 5qPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=1nic5ktiL0oztkEvHkl1TZtOKVIxBnVja4N+ELXzV0s=; b=JctLR+/unBlm0kybUxlzECq2BkaUydLcCgXOMAK8G+7+M4RL4tTFkcKq2onp+o2kNq P65J6wuN3CKHV+9CdIMzJdqBF6C3IpKU6h8A4J9H37bX7NRtlv0Zc4Kvi1dHHgefcBia 08+frB4H5G7Gp0rEUykUtbsDneJCumaBk7ErLbnoolv2VgDVRrohchhxGUkp8C7WyqcJ sdnNAgmTwN+eUpXLcOl/cPr6/MQpSB/aQzNP4UwcigzHHvL3f02evmddf0Z1w04tfCjb DcDlPEE9+QIlYRM0YZ+0z8XqHQSRp2gOJ1RvwDxcw4ynymX1fr+qxB9XWzC1BaMQs4Zc vY2Q== X-Gm-Message-State: AGi0PuYp6uhTSEcpCNG3J1G1VTCYfGBYr57EoWitj/XyzIx8iliNvi3x iVfZFi5f/nK0nzHFkq1Q6iIDlKtckhmPLUpjPixRsQ== X-Google-Smtp-Source: APiQypJik9bHDJALnPxNqlIAs4SM8SINEcNC+w7QI04fguYbFj2Loz6XnXxN/eZPHlkthjCHulM2JY5T1F2cvaCNJOc= X-Received: by 2002:a05:6e02:ca:: with SMTP id r10mr191568ilq.41.1588278687489; Thu, 30 Apr 2020 13:31:27 -0700 (PDT) MIME-Version: 1.0 References: <8756d18a-28ce-dda6-6300-24ae208351c2@agrell.info> In-Reply-To: <8756d18a-28ce-dda6-6300-24ae208351c2@agrell.info> From: Jeffrey Walton Date: Thu, 30 Apr 2020 16:31:11 -0400 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] bug: integer overflow in memmem() On Thu, Apr 30, 2020 at 2:30 PM Alfred Agrell wrote: > > To reproduce: Compile src/string/memmem.c with -fsanitize=undefined, then > > int main() > { > char a[4] = { -1,-1,-1,-1 }; > memmem(a, 4, a, 3); > memmem(a, 4, a, 4); > } > > Expected result: No output > > Actual (Ubuntu 18.04 x86_64, gcc 7.5.0, ): > > memmem.c:15:20: runtime error: left shift of 255 by 24 places cannot be > represented in type 'int' > memmem.c:16:20: runtime error: left shift of 255 by 24 places cannot be > represented in type 'int' > memmem.c:24:20: runtime error: left shift of 255 by 24 places cannot be > represented in type 'int' > memmem.c:25:20: runtime error: left shift of 255 by 24 places cannot be > represented in type 'int' >... > > I'm not aware of any compiler on any platform where it'll actually > break, so your choice whether this is a real bug. I didn't check if > similar issues exist elsewhere across musl. Try Intel ICC. It is ruthless and removes undefined behavior every chance it gets. It can usually break a program with UB that GCC, Clang and MSVC compile OK. Jeff