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

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.
> > 
> > The default is =unpaired, which warns about improperly terminated
> > bidirectional characters; e.g. a LRE without its appertaining PDF.  The
> 
> I like the default.

Great.

> Wording nit: maybe use "corresponding" rather than "appertaining"; I
> believe the latter has a sense that one is part of the other, when they
> are more like peers.

OK, fixed.

> > level =any warns about any use of bidirectional characters.
> 
> Terminology nit:
> The patch is referring to "bidirectional characters", but I think the
> term "bidirectional control characters" would be better.

Adjusted.

> 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

> [...snip...]
> 
> > diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> > index 06457ac739e..b047df0f125 100644
> > --- a/gcc/c-family/c.opt
> > +++ b/gcc/c-family/c.opt
> > @@ -374,6 +374,30 @@ Wbad-function-cast
> >  C ObjC Var(warn_bad_function_cast) Warning
> >  Warn about casting functions to incompatible types.
> >  
> > +Wbidi-chars
> > +C ObjC C++ ObjC++ Warning Alias(Wbidi-chars=,any,none)
> > +;
> > +
> > +Wbidi-chars=
> > +C ObjC C++ ObjC++ RejectNegative Joined Warning CPP(cpp_warn_bidirectional) CppReason(CPP_W_BIDIRECTIONAL) Var(warn_bidirectional) Init(bidirectional_unpaired) Enum(cpp_bidirectional_level)
> > +-Wbidi-chars=[none|unpaired|any] Warn about UTF-8 bidirectional characters.
> 
> "control characters"

Fixed.

> [...snip...]
> 
> >  
> > +@item -Wbidi-chars=@r{[}none@r{|}unpaired@r{|}any@r{]}
> > +@opindex Wbidi-chars=
> > +@opindex Wbidi-chars
> > +@opindex Wno-bidi-chars
> > +Warn about possibly misleading UTF-8 bidirectional characters in comments,
> 
> (and here again)

Fixed.

> > +string literals, character constants, and identifiers.  Such characters can
> > +change left-to-right writing direction into right-to-left (and vice versa),
> > +which can cause confusion between the logical order and visual order.  This
> > +may be dangerous; for instance, it may seem that a piece of code is not
> > +commented out, whereas it in fact is.
> > +
> > +There are three levels of warning supported by GCC@.  The default is
> > +@option{-Wbidi-chars=unpaired}, which warns about improperly terminated
> > +bidi contexts.  @option{-Wbidi-chars=none} turns the warning off.
> > +@option{-Wbidi-chars=any} warns about any use of bidirectional characters.
> 
> (and again)

Fixed.

> [...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.

> > diff --git a/gcc/testsuite/c-c++-common/Wbidi-chars-5.c b/gcc/testsuite/c-c++-common/Wbidi-chars-5.c
> > new file mode 100644
> > index 00000000000..efb26309b68
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/Wbidi-chars-5.c
> > @@ -0,0 +1,166 @@
> > +/* PR preprocessor/103026 */
> > +/* { dg-do compile } */
> > +/* { dg-options "-Wbidi-chars=unpaired -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.  */
> 
> Similar comment as above re block comments

I've extended the test too.

> [...snip...]
> 
> > diff --git a/libcpp/include/cpplib.h b/libcpp/include/cpplib.h
> > index 176f8c5bbce..60cf08ddd35 100644
> > --- a/libcpp/include/cpplib.h
> > +++ b/libcpp/include/cpplib.h
> > @@ -319,6 +319,17 @@ enum cpp_main_search
> >    CMS_system,  /* Search the system INCLUDE path.  */
> >  };
> >  
> > +/* The possible bidirectional characters checking levels, from least
> > +   restrictive to most.  */
> > +enum cpp_bidirectional_level {
> > +  /* No checking.  */
> > +  bidirectional_none,
> > +  /* Only detect unpaired uses of bidirectional characters.  */
> > +  bidirectional_unpaired,
> > +  /* Detect any use of bidirectional characters.  */
> > +  bidirectional_any
> > +};
> 
> As before, "control characters".

Fixed.

> [...snip...]
> 
> > @@ -539,6 +550,10 @@ struct cpp_options
> >    /* True if warn about differences between C++98 and C++11.  */
> >    bool cpp_warn_cxx11_compat;
> >  
> > +  /* Nonzero of bidirectional characters checking is on.  See enum
> 
> s/of/if/
> 
> and usual nit about "control characters".

Fixed.

> > +     cpp_bidirectional_level.  */
> > +  unsigned char cpp_warn_bidirectional;
> > +
> >    /* Dependency generation.  */
> >    struct
> >    {
> 
> [...snip...]
> 
> > diff --git a/libcpp/lex.c b/libcpp/lex.c
> > index fa2253d41c3..3fb518e202b 100644
> > --- a/libcpp/lex.c
> > +++ b/libcpp/lex.c
> > @@ -1164,6 +1164,300 @@ _cpp_process_line_notes (cpp_reader *pfile, int in_comment)
> >      }
> >  }
> >  
> > +namespace bidi {
> > +  enum class kind {
> > +    NONE, LRE, RLE, LRO, RLO, LRI, RLI, FSI, PDF, PDI
> > +  };
> > +
> > +  /* All the UTF-8 encodings of bidi characters start with E2.  */
> > +  constexpr uchar utf8_start = 0xe2;
> 
> Is there a difference between "constexpr" vs "const" here?  (sorry for
> my ignorance)

I just wanted to make sure that utf8_start will be usable in contexts where
an integral constant expression is required.  'const' objects need not be
initialized with compile-time constants, but 'constexpr' objects do.

> > +
> > +  /* A vector holding currently open bidi contexts.  We use a char for
> > +     each context, its LSB is 1 if it represents a PDF context, 0 if it
> > +     represents a PDI context.  The next bit is 1 if this context was open
> > +     by a bidi character written as a UCN, and 0 when it was UTF-8.  */
> > +  semi_embedded_vec <unsigned char, 16> vec;
> > +
> > +  /* Close the whole comment/identifier/string literal/character constant
> > +     context.  */
> > +  void on_close ()
> > +  {
> > +    vec.truncate (0);
> > +  }
> > +
> > +  /* Pop the last element in the vector.  */
> > +  void pop ()
> > +  {
> > +    unsigned int len = vec.count ();
> > +    gcc_checking_assert (len > 0);
> > +    vec.truncate (len - 1);
> > +  }
> > +
> > +  /* Return the context of the Ith element.  */
> > +  kind ctx_at (unsigned int i)
> > +  {
> > +    return (vec[i] & 1) ? kind::PDF : kind::PDI;
> > +  }
> > +
> > +  /* Return which context is currently opened.  */
> > +  kind current_ctx ()
> > +  {
> > +    unsigned int len = vec.count ();
> > +    if (len == 0)
> > +      return kind::NONE;
> > +    return ctx_at (len - 1);
> > +  }
> > +
> > +  /* Return true if the current context comes from a UCN origin, that is,
> > +     the bidi char which started this bidi context was written as a UCN.  */
> > +  bool current_ctx_ucn_p ()
> > +  {
> > +    unsigned int len = vec.count ();
> > +    gcc_checking_assert (len > 0);
> > +    return (vec[len - 1] >> 1) & 1;
> > +  }
> > +
> > +  /* We've read a bidi char, update the current vector as necessary.  */
> > +  void on_char (kind k, bool ucn_p)
> > +  {
> > +    switch (k)
> > +      {
> > +      case kind::LRE:
> > +      case kind::RLE:
> > +      case kind::LRO:
> > +      case kind::RLO:
> > +	vec.push (ucn_p ? 3u : 1u);
> > +	break;
> > +      case kind::LRI:
> > +      case kind::RLI:
> > +      case kind::FSI:
> > +	vec.push (ucn_p ? 2u : 0u);
> > +	break;
> 
> I don't like the hand-coded bit fields here, where bit 1 and bit 2 in
> the above have special meaning, but aren't clearly labelled as such.
> 
> Please can you at least use some kind of constant/define to make clear
> the meaning of the bits.  Even clearer would be bitfields; is there a
> performance reason for not using them?  (though this code is only
> called on bidi control chars, which presumably is a rare occurrence). 
> My patch here:
>   "[PATCH 2/2] Capture locations of bidi chars and underline ranges"
>     https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583160.html
> did some refactoring of this patch, replacing hand-coded bit
> manipulation with bitfields in a struct (as well as then using that as
> a good place to stach location_t values, and then using these
> locations).
> Would it be helpful if I split that part of my patch out?

I think they are just fine here, given they are used only in bidi:: and
not outside of it.  And I could just use a simple unsigned char in
semi_embedded_vec instead of inventing a new struct.

Your diagnostic patch changes it because you need to remember a location
too, so we're changing it anyway, so I left it be so that you have fewer
conflicts.

> [...snip...]
> 
> > +/* Parse a sequence of 3 bytes starting with P and return its bidi code.  */
> > +
> > +static bidi::kind
> > +get_bidi_utf8 (const unsigned char *const p)
> > +{
> > +  gcc_checking_assert (p[0] == bidi::utf8_start);
> > +
> > +  if (p[1] == 0x80)
> > +    switch (p[2])
> 
> get_bidi_utf8 accesss up to 2 bytes beyond "p"...
> 
> [...snip...]
> 
> ...and is called in various places such as...
> 
> > @@ -1218,6 +1519,13 @@ _cpp_skip_block_comment (cpp_reader *pfile)
> >  
> >  	  cur = buffer->cur;
> >  	}
> > +      /* If this is a beginning of a UTF-8 encoding, it might be
> > +	 a bidirectional character.  */
> > +      else if (__builtin_expect (c == bidi::utf8_start, 0) && warn_bidi_p)
> > +	{
> > +	  bidi::kind kind = get_bidi_utf8 (cur - 1);
> > +	  maybe_warn_bidi_on_char (pfile, cur, kind, /*ucn_p=*/false);
> > +	}
> 
> Are we guaranteed to have a '\n' at the end of the buffer?  (even for
> the final line of the file)  That would ensure that we don't read past
> the end of the buffer.

We've discussed this in our internal thread; I think I said that you
will always get a '\n' so this is not going to read past the end of
the buffer.  To be sure...

> Can we have testcases involving malformed UTF-8, in which, say:
> - the final byte of the input file is 0xe2
> - the final two bytes of the input file are 0xe2 0x80
> for each of block comment, C++-style comment, string-literal,
> identifier, etc?
> (or is that overkill?)

...I'd crafted a malformed text file using hexedit but couldn't get
it to crash.  I'd rather not include it in the testsuite though.

> [...snip...]
> 
> > @@ -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 (warn_bidi_p)
> > +	maybe_warn_bidi_on_close (pfile, pfile->buffer->cur);
> >        result = _cpp_interpret_identifier (pfile, base,
> >  					  pfile->buffer->cur - base);
> >        *spelling = cpp_lookup (pfile, base, pfile->buffer->cur - base);
> > @@ -1758,6 +2112,8 @@ static void
> >  lex_raw_string (cpp_reader *pfile, cpp_token *token, const uchar *base)
> >  {
> >    const uchar *pos = base;
> > +  const bool warn_bidi_p = (CPP_OPTION (pfile, cpp_warn_bidirectional)
> > +			    != bidirectional_none);
> 
> There are lots of places where the patch uses:
> 
> const bool warn_bidi_p = (CPP_OPTION (pfile, cpp_warn_bidirectional)
> > +			    != bidirectional_none);
> 
> Maybe make it an inline member function:
> 
>   bool warn_bidi_p () const
>   {
>     return CPP_OPTION (this, cpp_warn_bidirectional) != bidirectional_none;
>   }
> 
> so that these can all be:
> 
>   const bool warn_bidi_p = pfile->warn_bidi_p ();
> 
> ?

OK, I guess pfile->warn_bidi_p () is visually more appealing.  Since adding
a member function won't change the PODness of cpp_reader, I went with
your suggestion and added warn_bidi_p.

> Hope this is constructive; thanks again for the patch

Thanks a lot for taking a look!

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 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 |  33 ++
 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                                | 424 +++++++++++++++++++-
 23 files changed, 1298 insertions(+), 14 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: 4cdf7db9a39d18bd536d816a5751d4d3cf23808b

Message ID	YZQLlHfq740IOtje@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=x9Ua9IZU; 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 (ip-8-43-85-97.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 4HtxWx14V4z9sR4 for <incoming@patchwork.ozlabs.org>; Wed, 17 Nov 2021 06:51:25 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C240B385C410 for <incoming@patchwork.ozlabs.org>; Tue, 16 Nov 2021 19:51:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C240B385C410 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1637092282; bh=qGJCAbFmZLrc+/hSyLrynbpxzw2jtnNRTurWZthDv90=; 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=x9Ua9IZUvRKFRFbHMLK5zGx/fUPOLHI0b0GZJd24KtaSFaOKRcP+e2x+0L0FdzNgP FqPyqxa3QVjNq19T3OOoyMGyfEeMnkPO71ma0jxMMozAQig5ylta32Ve10ZtBwxX54 YfAcSRsN3Lr4rvV7MmBkjAJ06/LLCfeONXrXcv+Y= 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 B809D385781A for <gcc-patches@gcc.gnu.org>; Tue, 16 Nov 2021 19:50:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B809D385781A Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-349-jeKH2XZbN4K89MK5a5YXEA-1; Tue, 16 Nov 2021 14:50:50 -0500 X-MC-Unique: jeKH2XZbN4K89MK5a5YXEA-1 Received: by mail-qt1-f200.google.com with SMTP id 4-20020ac85744000000b002b2f329efc2so201930qtx.12 for <gcc-patches@gcc.gnu.org>; Tue, 16 Nov 2021 11:50:50 -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=qGJCAbFmZLrc+/hSyLrynbpxzw2jtnNRTurWZthDv90=; b=wGsf+fmVy8Doo5zRfV5bL5li/YdrnNvFx4BtqheDhO0O09Q23NoFg08zeEOdHoJfsd M0MkkrebONqLuYv885ohoTcS+ucYK5l82d23LMz1JFdvCN6/+2+NjPdDvlGsKjbJw5XH yY0TwtHFwz2aEOwnfAZykyOjDOySBHX2NWMPZzUrCMaCwl/AyeKmaui4Sqo3BOfjn9dB Pclq3STzFlnsaRJZYaVDHJHyy6nNtfdCPFXRRsqZNOV5fSN5TAzIohMpmgq3sdaa6LEl JqmYztCD/U4cooZ5Y33NygbL0OT31V++ExGOOnBwNr7k2KfKoZJGkI2yan7zQ9e6FK6A DuRw== X-Gm-Message-State: AOAM531KJhrOCCQaOxOfCHA3a1FV8MvErsIvw/Kccg+pDmUon3mn3ln+ EXfSfmfnLcFnE06a6YXBfvGCXZ26M1RLRX+Oguu/VTsHWQZLl0wYTFUAcQtROvrBOVae6MBUBXP jkOYVdRcNsSzBSRwDAQ== X-Received: by 2002:ad4:5f4c:: with SMTP id p12mr49260592qvg.33.1637092248047; Tue, 16 Nov 2021 11:50:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJxsEqStLS+rD91MkAtQ1m9Y3j0UKjyZMfyowHEFF473POKL3mzjstPbiBrAI0hwRvqXnFSsEQ== X-Received: by 2002:ad4:5f4c:: with SMTP id p12mr49260445qvg.33.1637092246684; Tue, 16 Nov 2021 11:50:46 -0800 (PST) Received: from redhat.com ([2601:184:4780:4310::aac2]) by smtp.gmail.com with ESMTPSA id y73sm8783930qkb.113.2021.11.16.11.50.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 11:50:46 -0800 (PST) Date: Tue, 16 Nov 2021 14:50:44 -0500 To: David Malcolm <dmalcolm@redhat.com> Subject: [PATCH v2] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026] Message-ID: <YZQLlHfq740IOtje@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> MIME-Version: 1.0 In-Reply-To: <a4463efe9cd50165a6fcd1ca05470a03595792f3.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.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, 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	[v2] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026] \| expand [v2] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

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

Commit Message

Comments

Patch