elf: Check corrupt VTENTRY relocation addend

[Jan Beulich]

On 25.09.2025 02:39, Alan Modra wrote:
> On Tue, Sep 23, 2025 at 04:42:51PM +0200, Jan Beulich wrote:
>> On 23.09.2025 13:57, Alan Modra wrote:
>>> On Tue, Sep 23, 2025 at 10:16:50AM +0800, H.J. Lu wrote:
>>>> --- a/bfd/elflink.c
>>>> +++ b/bfd/elflink.c
>>>> @@ -14895,6 +14895,15 @@ bfd_elf_gc_record_vtentry (bfd *abfd, asection *sec,
>>>>  	}
>>>>        size = (size + file_align - 1) & -file_align;
>>>>  
>>>> +      if (addend > size)
>>>
>>> For this to happen you must have had an overflow in prior expressions
>>> calculating size from addend, I think.  Perhaps it might be better to
>>> limit vtentry reloc addends to something a lot smaller than -8ul
>>> (which I think is effectively what your patch does), to prevent insane
>>> vtable memory allocation.  What is a reasonable limit to c++ vtable
>>> size?
>>
>> Can we really build in a heuristic like that? Arbitrarily complex class
>> hierarchies can have arbitrarily large vtables, I suppose.
> 
> We can in this case.  I doubt anyone would notice if gas
> .vtable_inherit and .vtable_entry disappeared along with all the
> support for VTINHERIT and VTENTRY relocs.  See gcc commit a0c8285b03a4.
> I am committing the following patch.
> 
> 
> PR 33452 SEGV in bfd_elf_gc_record_vtentry
> 
> Limit addends on vtentry relocs, otherwise ld might attempt to
> allocate a stupidly large array.  This also fixes the expression
> overflow leading to pr33452.  A vtable of 33M entries on a 64-bit
> host is surely large enough, especially considering that VTINHERIT
> and VTENTRY relocations are to support -fvtable-gc that disappeared
> from gcc over 20 years ago.

Oh, I didn't know this was only historic functionality.

Jan