[PATCH v2] elf: Check corrupt VTENTRY relocation overflow

[H.J. Lu]

On Tue, Sep 23, 2025 at 10:42 PM Jan Beulich <jbeulich@suse.com> 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.
>
> Jan

Here is the v2 patch to check the size calculation overflow instead.
OK for master?

Thanks.

-- 
H.J.

If VTENTRY relocation addend is too large, the size calculation will
overflow.  Check it to avoid linker crash later.

PR ld/33452
* elflink.c (bfd_elf_gc_record_vtentry): Return false if VTENTRY
relocation addend causes the size calculation overflow.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2-0001-elf-Check-corrupt-VTENTRY-relocation-overflow.patch
Type: text/x-patch
Size: 1283 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20250924/1c943a59/attachment-0001.bin>