From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id 20160386F439 for ; Thu, 17 Sep 2020 03:24:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 20160386F439 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-572-nJna0SyzOpSbNv6zGb-y5A-1; Wed, 16 Sep 2020 23:23:59 -0400 X-MC-Unique: nJna0SyzOpSbNv6zGb-y5A-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 10663801AEF; Thu, 17 Sep 2020 03:23:58 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-142.phx2.redhat.com [10.3.112.142]) by smtp.corp.redhat.com (Postfix) with ESMTP id AF05C1002397; Thu, 17 Sep 2020 03:23:57 +0000 (UTC) Subject: Re: [PATCH] warn for integer overflow in allocation calls (PR 96838) To: Martin Sebor , gcc-patches References: <83a00f2c-de4f-60d8-9399-a64671795eda@gmail.com> From: Jeff Law Message-ID: <1fea8304-a48b-6591-bab4-eb1469865bbd@redhat.com> Date: Wed, 16 Sep 2020 21:23:56 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <83a00f2c-de4f-60d8-9399-a64671795eda@gmail.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0.001 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="------------1CD7447F50F73BAFF4F2E9E3" Content-Language: en-US X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 03:24:19 -0000 This is a multi-part message in MIME format. --------------1CD7447F50F73BAFF4F2E9E3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 9/15/20 1:47 PM, Martin Sebor wrote: > Overflowing the size of a dynamic allocation (e.g., malloc or VLA) > can lead to a subsequent buffer overflow corrupting the heap or > stack.=C2=A0 The attached patch diagnoses a subset of these cases where > the overflow/wraparound is still detectable. > > Besides regtesting GCC on x86_64-linux I also verified the warning > doesn't introduce any false positives into Glibc or Binutils/GDB > builds on the same target. > > Martin > > gcc-96838.diff > > PR middle-end/96838 - missing warning on integer overflow in calls to all= ocation functions > > gcc/ChangeLog: > > =09PR middle-end/96838 > =09* calls.c (eval_size_vflow): New function. > =09(get_size_range): Call it. Add argument. > =09(maybe_warn_alloc_args_overflow): Diagnose overflow/wraparound. > =09* calls.h (get_size_range): Add argument. > > gcc/testsuite/ChangeLog: > > =09PR middle-end/96838 > =09* gcc.dg/Walloc-size-larger-than-19.c: New test. > =09* gcc.dg/Walloc-size-larger-than-20.c: New test. If an attacker can control an integer overflow that feeds an allocation, then they can do all kinds of bad things.=C2=A0 In fact, when my son was asking me attack vectors, this is one I said I'd look at if I were a bad guy. I'm a bit surprised you can't just query the range of the argument and get the overflow status out of that range, but I don't see that in the APIs.=C2=A0 How painful would it be to make that part of the API?=C2=A0 The conceptual model would be to just ask for the range of the argument to malloc which would include the range and a status bit indicating the computation might have overflowed. jeff --------------1CD7447F50F73BAFF4F2E9E3 Content-Type: application/pgp-keys; name="pEpkey.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pEpkey.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBFkbIO8BCACVIqDhDVh9ur8C+zNV1J/cXfwvVDAUcphDEFl4jyHqZORK4Pd3 Db8oWqLmQ8lOCr/VOS7lrCtdpVMQkLGOGA16oJ8g7hzhnojpjY09UjsoUiG7oKac uxj8skfp6SIx93Zl+iNYPRa4S+za6nY8qiVjyUuiyX04ZPZMrKp2c2sGi+HnBKUZ XGhrz/Jdzdox3tjajWZnObyynhEN6hn9L3KawTtGPE/R6A/1RhHTD9FQmIWIeucp aY5c6GNKXTFpj2VYx57LY5hve1R5vhrJIZcgwZAiOtmik5lVi96glY5h6bugRwpe xjhwORTLPBCkwiYotSxX99mWd6EHL576i5CNABEBAAG0GUplZmYgTGF3IDxsYXdA cmVkaGF0LmNvbT6JAU4EEwEIADgWIQR+niGjtnP5P/8PpRq8fP682pgzWwUCWRsg 7wIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRC8fP682pgzW5QGB/9VATJm x5235RB+8jiDYGXQf3vd9gBfPy/l1tsaK400eFAevDzfGvKmeCKe+uGnlrH3vyT8 rg9zqH+s5a1Y+lDXPOpJAFmmzbOLU4FW4ucbawmtYvBL65PqpQneCTYnC802/OAc xjm/OnemHlgeK6WicNsBTPwYN/0araDFUejyYBIFi9CNqqflwk5Z3brKbQ9bAYIk ysVLC/c3njKPmM0cWPFHG91ubLbWCHwTIK0+mAL714eTD74dXzOjO2ZDBPLGlFN/ kO3+YjaO6UOD2O8acvAMCivTkWLr7JwRgLIQDN2DkhQDd3LTPqQE/yOcMcXBTO+f xm8KG0iKQBqWMyGJuQENBFkbIO8BCACyqbOsv7XegSeea8XORt5zMaBVWKoSyhmm cCmlxZFS2cuYOBt79MO13lZE2DlO3Lv5IKikj/D4ketGVO4+h5psEMH5Yz5P8bx0 TmgwbK1GxPZrzeXozUFJDvvCDbIlT0v0pwUXuK3hg8Ieo2h5uTed/cn1OjySXW5B qLxN0cyr5hL+J6dcsHvKLT/N3nTgCQhoJXK2MrEMhAGgF3jKpMn3CoS4i/ZbNI2M QR6LWHwdZ95f0fI8NzHSfVzeLtzCKQec7nr9fgd6Ylk1ZpGWQUPlQmKjzYgeCeTK NO04cwt20WIrQWeWiZFPA0U86NDBdSBrYp4kG3dfIXE+wSSvE7qPABEBAAGJATYE GAEIACAWIQR+niGjtnP5P/8PpRq8fP682pgzWwUCWRsg7wIbDAAKCRC8fP682pgz W3REB/9cT7iKRPg/OK9bpLlllIEDM90IaKC79DQrv+fRudOR78cdV4XUwPSFnyHU sP3VJ4lDy5FhiKCwGie0BK53EsxgMrLy1L8hboFdTE4Vi0xzCheMaMVp4hATDU29 k1cuxu1VPpCa8E3mYeHjNV7ip0HN5L4Drfs8lRPJE/oM1vGs9DgQFZrCPPNRNGKC 97BH+DHccesEJr7tSsQrkPkt0z/FTKr5wIM02vSxOJjgmcVbGB7dc2j/Sx8loXmu KnuKtM35668kUG8jeJvSQk3o/VHpD27bhl0rR68R2jN6G6kQegMVb6dPu1Ius8rB E5rFw88J4JEb5q4hMNClWWUFHIdP =3DIDHe -----END PGP PUBLIC KEY BLOCK----- --------------1CD7447F50F73BAFF4F2E9E3--