[v3] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

On Tue, Nov 16, 2021 at 06:00:58PM -0500, David Malcolm wrote:
> > On Mon, Nov 15, 2021 at 06:15:40PM -0500, David Malcolm wrote:
> > > > On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote:
> > > > > Ping, can we conclude on the name?   IMHO, -Wbidirectional is just fine,
> > > > > but changing the name is a trivial operation. 
> > > > 
> > > > Here's a patch with a better name (suggested by Jonathan W.).  Otherwise no
> > > > changes.
> > > 
> > > Thanks for implementing this.
> > > 
> > > > 
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > > 
> > > > -- >8 --
> > > > From a link below:
> > > > "An issue was discovered in the Bidirectional Algorithm in the Unicode
> > > > Specification through 14.0. It permits the visual reordering of
> > > > characters via control sequences, which can be used to craft source code
> > > > that renders different logic than the logical ordering of tokens
> > > > ingested by compilers and interpreters. Adversaries can leverage this to
> > > > encode source code for compilers accepting Unicode such that targeted
> > > > vulnerabilities are introduced invisibly to human reviewers."
> > > > 
> > > > More info:
> > > > https://nvd.nist.gov/vuln/detail/CVE-2021-42574
> > > > https://trojansource.codes/
> > > > 
> > > > This is not a compiler bug.  However, to mitigate the problem, this patch
> > > > implements -Wbidi-chars=[none|unpaired|any] to warn about possibly
> > > > misleading Unicode bidirectional characters the preprocessor may encounter.
> 
> [...snip...]
> 
> > > 
> > > Terminology nit:
> > > The patch is referring to "bidirectional characters", but I think the
> > > term "bidirectional control characters" would be better.
> > 
> > Adjusted.
> 
> Thanks.
> 
> I wonder if the warning should be -Wbidi-control-chars, but I don't
> care enough to insist on it being changed.
> 
> >  
> > > For example, a passage of text containing both numbers and characters
> > > in a right-to-left script could be considered "bidirectional", since
> > > the numbers are written from left-to-right.
> > > 
> > > Specifically, the patch looks for these specific characters:
> > >   * U+202A LEFT-TO-RIGHT EMBEDDING
> > >   * U+202B RIGHT-TO-LEFT EMBEDDING
> > >   * U+202C POP DIRECTIONAL FORMATTING
> > >   * U+202D LEFT-TO-RIGHT OVERRIDE
> > >   * U+202E RIGHT-TO-LEFT OVERRIDE
> > >   * U+2066 LEFT-TO-RIGHT ISOLATE
> > >   * U+2067 RIGHT-TO-LEFT ISOLATE
> > >   * U+2068 FIRST STRONG ISOLATE
> > >   * U+2069 POP DIRECTIONAL ISOLATE
> > > 
> > > However, the following characters could also be considered as
> > > "bidirectional control characters":
> > >   * U+200E ‎LEFT-TO-RIGHT MARK (UTF-8: E2 80 8E)
> > >   * U+200F ‎RIGHT-TO-LEFT MARK (UTF-8: E2 80 8F)
> > > but aren't checked for in the patch.  Should they be?  I can imagine
> > > ways in which they could be abused, so I think so.
> > 
> > I'd only intended to check the bidi chars described in the original
> > trojan source pdf, but I added checking for U+200E/U+200F too, since
> > it was easy enough.  AFAIK they aren't popped by a PDF/PDI like the
> > rest, so don't need to go on the vec, and so we only warn with =any.
> > Tests: Wbidi-chars-16.c + Wbidi-chars-17.c
> 
> Thanks.  I took a look through the revised patch and I think you
> updated things correctly.
> 
> [...snip...]
> 
> > > > diff --git a/gcc/testsuite/c-c++-common/Wbidi-chars-4.c b/gcc/testsuite/c-c++-common/Wbidi-chars-4.c
> > > > new file mode 100644
> > > > index 00000000000..9fd4bc535ca
> > > > --- /dev/null
> > > > +++ b/gcc/testsuite/c-c++-common/Wbidi-chars-4.c
> > > > @@ -0,0 +1,166 @@
> > > > +/* PR preprocessor/103026 */
> > > > +/* { dg-do compile } */
> > > > +/* { dg-options "-Wbidi-chars=any -Wno-multichar -Wno-overflow" } */
> > > > +/* Test all bidi chars in various contexts (identifiers, comments,
> > > > +   string literals, character constants), both UCN and UTF-8.  The bidi
> > > > +   chars here are properly terminated, except for the character constants.  */
> > > > +
> > > > +/* a b c LRE‪ 1 2 3 PDF‬ x y z */
> > > > +/* { dg-warning "U\\+202A" "" { target *-*-* } .-1 } */
> > > > +/* a b c RLE‫ 1 2 3 PDF‬ x y z */
> > > > +/* { dg-warning "U\\+202B" "" { target *-*-* } .-1 } */
> > > > +/* a b c LRO‭ 1 2 3 PDF‬ x y z */
> > > > +/* { dg-warning "U\\+202D" "" { target *-*-* } .-1 } */
> > > > +/* a b c RLO‮ 1 2 3 PDF‬ x y z */
> > > > +/* { dg-warning "U\\+202E" "" { target *-*-* } .-1 } */
> > > > +/* a b c LRI⁦ 1 2 3 PDI⁩ x y z */
> > > > +/* { dg-warning "U\\+2066" "" { target *-*-* } .-1 } */
> > > > +/* a b c RLI⁧ 1 2 3 PDI⁩ x y */
> > > > +/* { dg-warning "U\\+2067" "" { target *-*-* } .-1 } */
> > > > +/* a b c FSI⁨ 1 2 3 PDI⁩ x y z */
> > > > +/* { dg-warning "U\\+2068" "" { target *-*-* } .-1 } */
> > > 
> > > AIUI the Unicode bidirectionality algorithm works at the line level,
> > > and so each line in a block comment should be checked individually for
> > > unclossed bidi control chars, rather than a block comment as a whole. 
> > > Hence I think the test case needs to have block comment test coverage
> > > for:
> > > - single line blocks
> > > - first line of a multiline block comment
> > > - middle line of a multiline block comment
> > > - final line of a multiline block comment
> > > but I think the patch as it stands is only checking for the first of
> > > these four cases.
> > 
> > The patch handles all of them, because of:
> > 1534           if (warn_bidi_p)
> > 1535             maybe_warn_bidi_on_close (pfile, cur);
> > in _cpp_skip_block_comment, but I was lacking some more testing, so I've
> > added some testing, and included a new test: Wbidi-chars-15.c.
> 
> All of the cases in Wbidi-chars-15.c only test for unparired chars in a
> middle line of a multiline block comment; I don't think the patch has
> any explicit coverage for unpaired control chars happening in the first
> line and last lines of *multiline* block comments.  So it would be good
> if Wbidi-chars-15.c could gain some coverage for that (don't have to
> handle all the different chars).

Sorry for a dumb question, but is this what you have in mind?

/* LRE
   PDF */
/* FSI
   PDI */
and check that we warn for these?

> > > > @@ -1505,13 +1855,17 @@ lex_identifier (cpp_reader *pfile, const uchar *base, bool starts_ucn,
> > > >      {
> > > >        /* Slower version for identifiers containing UCNs
> > > >  	 or extended chars (including $).  */
> > > > -      do {
> > > > -	while (ISIDNUM (*pfile->buffer->cur))
> > > > -	  {
> > > > -	    NORMALIZE_STATE_UPDATE_IDNUM (nst, *pfile->buffer->cur);
> > > > -	    pfile->buffer->cur++;
> > > > -	  }
> > > > -      } while (forms_identifier_p (pfile, false, nst));
> > > > +      do
> > > > +	{
> > > > +	  while (ISIDNUM (*pfile->buffer->cur))
> > > > +	    {
> > > > +	      NORMALIZE_STATE_UPDATE_IDNUM (nst, *pfile->buffer->cur);
> > > > +	      pfile->buffer->cur++;
> > > > +	    }
> > > > +	}
> > > > +      while (forms_identifier_p (pfile, false, nst));
> > > 
> > > Is the above purely a whitespace change?
> > 
> > Yes.
> 
> If I'm reading things correctly, these lines in the existing code were
> correctly indented, so is there a purpose to this change?  If not,
> please can you remove this change from the patch (to minimize the
> change to the history).

I dropped that change then.  Sometimes it's hard to resist fixing
formatting.  ;)

> [...snip...]
> 
> > +/* We're closing a bidi context, that is, we've encountered a newline,
> > +   are closing a C-style comment, or are at the end of a string literal,
> > +   character constant, or identifier.  Warn if this context was not
> > +   properly terminated by a PDI or PDF.  P points to the last character
> > +   in this context.  */
> > +
> > +static void
> > +maybe_warn_bidi_on_close (cpp_reader *pfile, const uchar *p)
> > +{
> > +  if (CPP_OPTION (pfile, cpp_warn_bidirectional) == bidirectional_unpaired
> > +      && bidi::vec.count () > 0)
> > +    {
> > +      const location_t loc
> > +	= linemap_position_for_column (pfile->line_table,
> > +				       CPP_BUF_COLUMN (pfile->buffer, p));
> > +      cpp_warning_with_line (pfile, CPP_W_BIDIRECTIONAL, loc, 0,
> > +			     "unpaired UTF-8 bidirectional character "
> > +			     "detected");
> > +    }
> 
> Sorry, I missed this one in my initial review, should be "control
> character" here.

Fixed.

> [...snip...]
> 
> OK for trunk with the above nits fixed.

Thanks again for the review.

I'll push this once the test question above is resolved.

-- >8 --
From a link below:
"An issue was discovered in the Bidirectional Algorithm in the Unicode
Specification through 14.0. It permits the visual reordering of
characters via control sequences, which can be used to craft source code
that renders different logic than the logical ordering of tokens
ingested by compilers and interpreters. Adversaries can leverage this to
encode source code for compilers accepting Unicode such that targeted
vulnerabilities are introduced invisibly to human reviewers."

More info:
https://nvd.nist.gov/vuln/detail/CVE-2021-42574
https://trojansource.codes/

This is not a compiler bug.  However, to mitigate the problem, this patch
implements -Wbidi-chars=[none|unpaired|any] to warn about possibly
misleading Unicode bidirectional control characters the preprocessor may
encounter.

The default is =unpaired, which warns about improperly terminated
bidirectional control characters; e.g. a LRE without its corresponding PDF.
The level =any warns about any use of bidirectional control characters.

This patch handles both UCNs and UTF-8 characters.  UCNs designating
bidi characters in identifiers are accepted since r204886.  Then r217144
enabled -fextended-identifiers by default.  Extended characters in C/C++
identifiers have been accepted since r275979.  However, this patch still
warns about mixing UTF-8 and UCN bidi characters; there seems to be no
good reason to allow mixing them.

We warn in different contexts: comments (both C and C++-style), string
literals, character constants, and identifiers.  Expectedly, UCNs are ignored
in comments and raw string literals.  The bidirectional control characters
can nest so this patch handles that as well.

I have not included nor tested this at all with Fortran (which also has
string literals and line comments).

Dave M. posted patches improving diagnostic involving Unicode characters.
This patch does not make use of this new infrastructure yet.

	PR preprocessor/103026

gcc/c-family/ChangeLog:

	* c.opt (Wbidi-chars, Wbidi-chars=): New option.

gcc/ChangeLog:

	* doc/invoke.texi: Document -Wbidi-chars.

libcpp/ChangeLog:

	* include/cpplib.h (enum cpp_bidirectional_level): New.
	(struct cpp_options): Add cpp_warn_bidirectional.
	(enum cpp_warning_reason): Add CPP_W_BIDIRECTIONAL.
	* internal.h (struct cpp_reader): Add warn_bidi_p member
	function.
	* init.c (cpp_create_reader): Set cpp_warn_bidirectional.
	* lex.c (bidi): New namespace.
	(get_bidi_utf8): New function.
	(get_bidi_ucn): Likewise.
	(maybe_warn_bidi_on_close): Likewise.
	(maybe_warn_bidi_on_char): Likewise.
	(_cpp_skip_block_comment): Implement warning about bidirectional
	control characters.
	(skip_line_comment): Likewise.
	(forms_identifier_p): Likewise.
	(lex_identifier): Likewise.
	(lex_string): Likewise.
	(lex_raw_string): Likewise.

gcc/testsuite/ChangeLog:

	* c-c++-common/Wbidi-chars-1.c: New test.
	* c-c++-common/Wbidi-chars-2.c: New test.
	* c-c++-common/Wbidi-chars-3.c: New test.
	* c-c++-common/Wbidi-chars-4.c: New test.
	* c-c++-common/Wbidi-chars-5.c: New test.
	* c-c++-common/Wbidi-chars-6.c: New test.
	* c-c++-common/Wbidi-chars-7.c: New test.
	* c-c++-common/Wbidi-chars-8.c: New test.
	* c-c++-common/Wbidi-chars-9.c: New test.
	* c-c++-common/Wbidi-chars-10.c: New test.
	* c-c++-common/Wbidi-chars-11.c: New test.
	* c-c++-common/Wbidi-chars-12.c: New test.
	* c-c++-common/Wbidi-chars-13.c: New test.
	* c-c++-common/Wbidi-chars-14.c: New test.
	* c-c++-common/Wbidi-chars-15.c: New test.
	* c-c++-common/Wbidi-chars-16.c: New test.
	* c-c++-common/Wbidi-chars-17.c: New test.
---
 gcc/c-family/c.opt                          |  24 ++
 gcc/doc/invoke.texi                         |  21 +-
 gcc/testsuite/c-c++-common/Wbidi-chars-1.c  |  12 +
 gcc/testsuite/c-c++-common/Wbidi-chars-10.c |  27 ++
 gcc/testsuite/c-c++-common/Wbidi-chars-11.c |  13 +
 gcc/testsuite/c-c++-common/Wbidi-chars-12.c |  19 +
 gcc/testsuite/c-c++-common/Wbidi-chars-13.c |  17 +
 gcc/testsuite/c-c++-common/Wbidi-chars-14.c |  38 ++
 gcc/testsuite/c-c++-common/Wbidi-chars-15.c |  39 ++
 gcc/testsuite/c-c++-common/Wbidi-chars-16.c |  26 ++
 gcc/testsuite/c-c++-common/Wbidi-chars-17.c |  30 ++
 gcc/testsuite/c-c++-common/Wbidi-chars-2.c  |   9 +
 gcc/testsuite/c-c++-common/Wbidi-chars-3.c  |  11 +
 gcc/testsuite/c-c++-common/Wbidi-chars-4.c  | 188 +++++++++
 gcc/testsuite/c-c++-common/Wbidi-chars-5.c  | 188 +++++++++
 gcc/testsuite/c-c++-common/Wbidi-chars-6.c  | 155 ++++++++
 gcc/testsuite/c-c++-common/Wbidi-chars-7.c  |   9 +
 gcc/testsuite/c-c++-common/Wbidi-chars-8.c  |  13 +
 gcc/testsuite/c-c++-common/Wbidi-chars-9.c  |  29 ++
 libcpp/include/cpplib.h                     |  18 +-
 libcpp/init.c                               |   1 +
 libcpp/internal.h                           |   7 +
 libcpp/lex.c                                | 408 +++++++++++++++++++-
 23 files changed, 1295 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-1.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-10.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-11.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-12.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-13.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-14.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-15.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-16.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-17.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-2.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-3.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-4.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-5.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-6.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-7.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-8.c
 create mode 100644 gcc/testsuite/c-c++-common/Wbidi-chars-9.c

base-commit: 6b1695f4a094f99575c9d067da6277bb4302fb89

Message ID	YZROxBnxZQCTYdzl@redhat.com
State	New
Headers	show Return-Path: <gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org> X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=U0EE1HUN; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=<UNKNOWN>) Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4Hv3vj5QDSz9sRR for <incoming@patchwork.ozlabs.org>; Wed, 17 Nov 2021 11:38:56 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8AE93385DC06 for <incoming@patchwork.ozlabs.org>; Wed, 17 Nov 2021 00:38:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8AE93385DC06 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1637109534; bh=6x7z6UJhPeGnYzOuT+pcVD3XmGsuEku32CTt/0fMSxY=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=U0EE1HUNAbXwMspbydOOvmUBhyIIaSAxLWi2ZwBhCzkbGYgzURVcVDx/rC8wK1kzM MEZN7lpNf4jeskQSKcOonWGw7mm3KXLL5zGRU2dK8UBZNYXDkyIMAaLqaGjAAJ6YeA Fl+jA8IM85dq9NmEDYMe9/2k3dKlc0K94vaPDimI= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 69645385782F for <gcc-patches@gcc.gnu.org>; Wed, 17 Nov 2021 00:37:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 69645385782F Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-47-jZ85-JyJOBW5bLa3hEtGOg-1; Tue, 16 Nov 2021 19:37:30 -0500 X-MC-Unique: jZ85-JyJOBW5bLa3hEtGOg-1 Received: by mail-qv1-f72.google.com with SMTP id kd7-20020a056214400700b003b54713452cso1004739qvb.13 for <gcc-patches@gcc.gnu.org>; Tue, 16 Nov 2021 16:37:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=6x7z6UJhPeGnYzOuT+pcVD3XmGsuEku32CTt/0fMSxY=; b=SCf6VSJBnKOZpQslzM3+7c/0E30la2Z8N3M03OvLFTjqQB6BTTojJZz60YbArl5tF8 Dc7W+y4xU4w5VZoQwfc12wTfwZ8P6omedGNodhxHMIdOaLlFL9a4P/MRrDRGAfKiqdUX eN2u51xCL8PUe2tdSzMe3VSohH4l3ei/FCVIIXZ0cSKrPybEte6sH//L+sc3PR53qy55 M3qxfYbBTw3rpweCFJninOY9qxr3LihCmGYZxoSo9XOxhtpv1embiUkLyyb1Cblgf5S/ CPyKPRgyjnJ+vxXDkCLlLO9lTpfEXXa4aXjgOZvCvotMNxvHTM4jHgeocc0wR8XOnsGC CFVw== X-Gm-Message-State: AOAM531X33Ll0NL29QoEy5+a8AQYUgK4cF7ucQyPFS20vg8daRWQaV9j 62If0BHgQu3RDe1VZMN/wKnXMgjCAeNfv3tPuJgOeLikMF5stoxlMqRBHAXFddjYkQBLoOyVKNt mmecYarukb8cJByhTSw== X-Received: by 2002:a37:620d:: with SMTP id w13mr9968955qkb.44.1637109448058; Tue, 16 Nov 2021 16:37:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJx8MQ2hBzQQu5RBzyrQMh81nDHPcs0/AeYgzMtN281uF08X3NE5fM6HU5DONdyCou3G5CcXcg== X-Received: by 2002:a37:620d:: with SMTP id w13mr9968869qkb.44.1637109447093; Tue, 16 Nov 2021 16:37:27 -0800 (PST) Received: from redhat.com ([2601:184:4780:4310::aac2]) by smtp.gmail.com with ESMTPSA id g19sm3381343qtg.82.2021.11.16.16.37.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 16:37:26 -0800 (PST) Date: Tue, 16 Nov 2021 19:37:24 -0500 To: David Malcolm <dmalcolm@redhat.com> Subject: [PATCH v3] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026] Message-ID: <YZROxBnxZQCTYdzl@redhat.com> References: <20211101163652.36794-1-polacek@redhat.com> <alpine.DEB.2.22.394.2111012158330.1978253@digraph.polyomino.org.uk> <YYFzA3Z4rPwTo927@redhat.com> <49fc8d97-4cc7-5c78-d65a-02ea1419f483@gmail.com> <YYGW5eiZhSxq6aHl@redhat.com> <YYmXt6jB3Qq3qPIW@redhat.com> <YZKY2b8utf/5/f6o@redhat.com> <a4463efe9cd50165a6fcd1ca05470a03595792f3.camel@redhat.com> <YZQLlHfq740IOtje@redhat.com> <5422a6074f9a8877158b733c5acb2a9eecd4c000.camel@redhat.com> MIME-Version: 1.0 In-Reply-To: <5422a6074f9a8877158b733c5acb2a9eecd4c000.camel@redhat.com> User-Agent: Mutt/2.1.3 (2021-09-10) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-13.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Marek Polacek via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Marek Polacek <polacek@redhat.com> Cc: Jakub Jelinek <jakub@redhat.com>, Martin Sebor <msebor@redhat.com>, GCC Patches <gcc-patches@gcc.gnu.org>, Joseph Myers <joseph@codesourcery.com> Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org>
Series	[v3] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026] \| expand [v3] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

[v3] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

Commit Message

Comments

Patch