From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 17F65386191C; Tue, 1 Jun 2021 09:53:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 17F65386191C From: "matmal01 at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/100665] [hwsanitizer] nested funtion pointer is tagged but never checked. Date: Tue, 01 Jun 2021 09:53:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: sanitizer X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: matmal01 at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2021 09:53:07 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100665 Matthew Malcomson changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Matthew Malcomson --- (In reply to Hongtao.liu from comment #2) > (In reply to Matthew Malcomson from comment #1) > > Given that, the question of whether the function pointer (i.e. the poin= ter to > > the trampoline inside that object) should be tagged when passed elsewhe= re > > then > > has a few benefits: > > 1) In this case there is no check performed, but there may be checks > > performed > > if e.g. this function pointer gets cast to an integer pointer and so= me > > code > > elsewhere attempts to read that integer. > I'm not sure there're cases where code pointers are casted to integer > pointers. But consider the above comment, I agree that tag is needed for = the > object. Fair ;-). My reasoning was along the lines of "it's an escaped pointer, and I don't k= now what other code will do with it" than actually expecting that to happen.=