This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: V2 [PATCH] Check multiple NT_GNU_PROPERTY_TYPE_0 notes [BZ #23509]

On Thu, Sep 20, 2018 at 1:54 AM, Florian Weimer <> wrote:
> * H. J. Lu:
>> From e1c6cdeb7530c37ddb6688b17435c1c9a373a09c Mon Sep 17 00:00:00 2001
>> From: "H.J. Lu" <>
>> Date: Fri, 10 Aug 2018 18:43:22 -0700
>> Subject: [PATCH] Check multiple NT_GNU_PROPERTY_TYPE_0 notes [BZ #23509]
>> The older linker treats section as a generic note
>> section and just concatenates all sections from the
>> inputs to the output.  When the older linker is used to created the
>> program on CET-enabled OS, the generated output has
>> section with multiple NT_GNU_PROPERTY_TYPE_0 notes whose IBT and SHSTK
>> enable bits are set even if the program isn't CET enabled.  Such program
>> will crash on CET-enabled machines.  This patch updates the note parser:
>> 1. Skip note parsing if a NT_GNU_PROPERTY_TYPE_0 note has been processed.
>> 2. Check multiple NT_GNU_PROPERTY_TYPE_0 notes.
>>       [BZ #23509]
>>       * sysdeps/x86/dl-prop.h (_dl_process_cet_property_note): Skip
>>       note parsing if a NT_GNU_PROPERTY_TYPE_0 note has been processed.
>>       Update the l_cet field when processing NT_GNU_PROPERTY_TYPE_0 note.
>>       Check multiple NT_GNU_PROPERTY_TYPE_0 notes.
>>       * sysdeps/x86/link_map.h (l_cet): Expand to 3 bits,  Add
>>       lc_unknown.
> As far as I can tell, this patch catches only the case where a single
> PT_NOTE segment contains multiple notes.  If there are multiple PT_NOTE
> segments with notes, and each one contains a single note, the patch will
> still enable CET.

I believe this is covered by CET smoke test:

My patch should work in all cases.  If it misses some cases, please add it
to master branch at

under the "note" directory.

> Is my summary accurate?  Do you think it is safe to treat PT_NOTE
> segments in isolation?

What do you mean by that?  The only assumption I made is that
property note must follow the spec.  Any violation makes it invalid.

> If yes, this should be mentioned in the commit message.
> This seems to be an unrelated change?
> +             /* Property type must be in ascending order.  */
> +             if (type < last_type)
> +               return;

This is the part of property spec.  If properties aren't properly
sorted, it is invalid.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]