[PATCH v2] elf: Check corrupt VTENTRY relocation overflow
H.J. Lu
hjl.tools@gmail.com
Thu Sep 25 06:29:21 GMT 2025
On Thu, Sep 25, 2025 at 2:00 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 23.09.2025 23:25, H.J. Lu wrote:
> > 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.
> >
> > Here is the v2 patch to check the size calculation overflow instead.
> > OK for master?
>
> Isn't this superseded by Alan's patch?
>
> Jan
I think so.
--
H.J.
More information about the Binutils
mailing list