From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id E9D903858C31 for ; Fri, 17 Feb 2023 13:48:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E9D903858C31 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at Received: from [192.168.0.221] (84-115-221-110.cable.dynamic.surfer.at [84.115.221.110]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4PJCnz0QQTz1LM0V; Fri, 17 Feb 2023 14:48:39 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4PJCnz0QQTz1LM0V DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1676641719; bh=UmO05chJU2IK2RAy/TR4Dkekl1rr59uatlcc4ZhUd78=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=hxn0JhhBymYF/kzGx4mn4AUMUfGZBzDSl6fnTx1tuoSa+dU6Csc+J8CMDwrWNVMPK HpJpLz28TQpjQAVIxA0f3hVDDq+eINJ53VNJKagj8oKZJio6HM9XkGZeHQkv9TTTgU xhqIcTOZ+YFpbDQMUTQ8651cEpuAtSe4sT7iireA= Message-ID: <6edeb3c197c327c1c6639d322c53ec6056039a33.camel@tugraz.at> Subject: Re: Missed warning (-Wuse-after-free) From: Martin Uecker To: Alejandro Colomar , GCC , Jonathan Wakely Cc: Iker Pedrosa , Florian Weimer , Paul Eggert , Michael Kerrisk , =?UTF-8?Q?J=E2=82=91=E2=82=99=E2=82=9B?= Gustedt , David Malcolm , Sam James Date: Fri, 17 Feb 2023 14:48:38 +0100 In-Reply-To: <0049730a-e28c-0e0f-8d92-695395f1ec21@gmail.com> References: <8ed6d28c-69dc-fed8-5ab5-99f685f06fac@gmail.com> <38e7e994a81d2a18666404dbaeb556f3508a6bd6.camel@redhat.com> <23d3a3ff-adad-ac2e-92a6-4e19f4093143@gmail.com> <2148ef80dee2a034ee531d662fc8709d26159ec5.camel@tugraz.at> <0049730a-e28c-0e0f-8d92-695395f1ec21@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1+deb11u1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -0.4 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am Freitag, dem 17.02.2023 um 12:35 +0100 schrieb Alejandro Colomar: > Hi Martin, > > On 2/17/23 09:12, Martin Uecker wrote: > > Am Freitag, dem 17.02.2023 um 02:04 +0100 schrieb Alejandro Colomar > > > > > > > > > > [...] > > > > > > > > > > > I'm not convinced that it's useful to the end-user to warn about > > > > the > > > > "use of q itself" case. > > > > > > I didn't quote the standard because I couldn't find it.  I was > > > searching in C11, > > > and it seems that it was only implicitly Undefined Behavior, without > > > explicit > > > spelling (the value of the pointer was indeterminate, according to > > > C11). > > > > The value becomes indeterminate according to 6.2.4p2 in C11. > > An indeterminate value may be a trap representation 3.19.2 > > If such a trap representation is read (the pointer, not > > just the pointed-to object), the behavior is undefined > > according to 6.2.6.1p5. So it is explitely UB and was > > already in C99 or even before. > > What if the comparison is performed as uintptr_t? According to the standard, it is allowed to convert a valid pointer to uintptr_t and then compare it after the object is freed. Unfortunately, many compilers will miscompile such comparisons. This does not only affect C/C++ but also happens in "safe" Rust: https://godbolt.org/z/e53b5a53q But conversion to uintptr_t after the object is freed is undefined behavior. > You wouldn't have trap representations, would you? > Or we could even go to memcmp(3) to compare as char, > if paranoic enough :) We renamed "trap representations" to  "non-value representation" in C2X because people tend to misunderstand this term. It does not necessarily imply a trap. It simply means that the object representation does not correspond to a valid value of the type. A pointer that is not NULL but also does not point to an object would have a trap representation (now: "non-value representation"). A boolean that stores a representation that does not correspond to true or false is also a non-value  representation. In such cases already a load  (lvalue conversion) of such a value causes undefined behavior. Existing (correct) compiler optimizations can break code which does comparisons of pointers to dead objects. So it is not really safe to use such pointers even if the architecture does not trap on load of such pointers. For pointers, there is also the subtle issue that the representation might be the same in memory as a new valid pointer to a new object, but it is still considered a trap representation due to provenance. > > > > > > > Now C23 will better clarify that reading such a pointer value (not > > > ever dereferencing) is Undefined Behavior. > > > > We did not change this for C23. > > C11: > > The value of a pointer becomes indeterminate when > the object it points to (or just past) > reaches the end of its lifetime. > > > C2x (N3054 is the latest I know): > > If a pointer value is used in an evaluation after > the object the pointer points to (or just past) > reaches the end of its lifetime, > the behavior is undefined. > > > > This new wording doesn't even allow one to use memcmp(3); > just reading the pointer value, however you do it, is UB. memcmp would not use the pointer value but work on the representation bytes and is still allowed. Martin > > > > Only the terminology regarding trap representation > > (now: non-value representation) and indeterminate > > values (now: indeterminate representation) was revised. > > > > > > There are proposal to define bevahior for such > > pointers, but I think this would be a mistake. > > (although somehow I ended up being a co-author > > of this paper), > > > > The reason is that every use of such a pointer  > > risks running into sublte issues related to pointer  > > provenance. > > > > So in my opinion it would be very useful to warn about > > all uses of invalid pointers, because fixing this is > > much easier than understanding and fixing provenance > > issues which might arise from incorrect use of such > > pointers. > > Agree; making this defined behavior doesn't seem a good idea. > > Cheers, > > Alex > > > > > > > Martin >