[Bug demangler/88783] integer overflow in libiberty, heap overflow will be triggered in nm

[siddhesh at gotplt dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88783

Siddhesh Poyarekar  changed:

   What|Removed |Added

 CC||siddhesh at gotplt dot org

--- Comment #9 from Siddhesh Poyarekar  ---
gcc version of libiberty hasn't had this issue since the following change which
removed the potential overflow.  The POC also appears fixed with binutils 2.35;
from code inspection it should be fixed in 2.32 and later.  This ought to be
closed.

ommit 6c8120c5ff130e03d32ff15a8f0d0e703592a2af
Author: Jason Merrill 
Date:   Sat Dec 22 19:06:34 2018 -0500

Remove support for demangling GCC 2.x era mangling schemes.

libiberty/
* cplus-dem.c: Remove cplus_mangle_opname, cplus_demangle_opname,
internal_cplus_demangle, and all subroutines.
(libiberty_demanglers): Remove entries for ancient GNU (pre-3.0),
Lucid, ARM, HP, and EDG demangling styles.
(cplus_demangle): Remove 'work' variable.  Don't call
internal_cplus_demangle.
include/
* demangle.h: Remove support for ancient GNU (pre-3.0), Lucid,
ARM, HP, and EDG demangling styles.

From-SVN: r267363

[Bug tree-optimization/103456] [12 Regression] gcc/gcc.c:9502:8: runtime error: load of address 0x0000009f5037 with insufficient space for an object of type 'const char' since r12-5548-g4a2007594cff78

[siddhesh at gotplt dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103456

Siddhesh Poyarekar  changed:

   What|Removed |Added

 CC||siddhesh at gotplt dot org

--- Comment #1 from Siddhesh Poyarekar  ---
I'm looking at this, I don't seem to have the right blessings to assign it to
myself though.

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

[siddhesh at gotplt dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836

Siddhesh Poyarekar  changed:

   What|Removed |Added

 CC||siddhesh at gotplt dot org

--- Comment #5 from Siddhesh Poyarekar  ---
Vim explicitly disables _FORTIFY_SOURCE to keep its use of 1-sized trailing
arrays:

https://github.com/vim/vim/issues/5581

so either they haven't tested with more recent gcc or they're hitting a corner
case where __builtin_object_size does return the subscript value for the
trailing member.

I inherited the __builtin_object_size behaviour in
__builtin_dynamic_object_size to remain consistent with current behaviour:

ok:  sizeof(*working) == 24
ok:  sizeof(working->c) == 16
ok:  __builtin_object_size(working, 1) == -1
ok:  __builtin_object_size(working->c, 1) == 16
ok:  __builtin_dynamic_object_size(working, 1) == -1
ok:  __builtin_dynamic_object_size(working->c, 1) == 16
ok:  sizeof(*broken) == 24
ok:  sizeof(broken->c) == 16
ok:  __builtin_object_size(broken, 1) == -1
WAT: __builtin_object_size(broken->c, 1) == -1 (expected 16)
ok:  __builtin_dynamic_object_size(broken, 1) == -1
WAT: __builtin_dynamic_object_size(broken->c, 1) == -1 (expected 16)


However in theory if the pass can see the allocation, it should be able to
build the right expression for object size.

I'm updating the patchset to meld the two passes into one and I could add
-fstrict-flex-arrays as one of the patches to make this stricter.

[Bug middle-end/101397] [11 Regression] spurious warning writing to the result of stpcpy minus 1

[siddhesh at gotplt dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101397

Siddhesh Poyarekar  changed:

   What|Removed |Added

 CC||siddhesh at gotplt dot org

--- Comment #7 from Siddhesh Poyarekar  ---
(In reply to CVS Commits from comment #4)
> The master branch has been updated by Martin Sebor :
> 
> https://gcc.gnu.org/g:8bf5b49ebd2176b8c535147377381dd07fbdd643
> 
> commit r12-2422-g8bf5b49ebd2176b8c535147377381dd07fbdd643
> Author: Martin Sebor 
> Date:   Tue Jul 20 13:48:20 2021 -0600
> 
> Correct stpcpy offset computation for -Warray-bounds et al. [PR101397].

This causes a crash with the following program due to an infinite recursion:

typedef __SIZE_TYPE__ size_t;

void
__attribute__ ((noinline))
foo (size_t x)
{
  struct T { char buf[64]; char buf2[64]; } t;
  char *p = &t.buf[8];
  char *r = t.buf2;
  size_t i;

  for (i = 0; i < x; i++)
{
  r = __builtin_mempcpy (r, p, i);
  p = r + 1;
}
}

$ cc1.r12-2422 -quiet -o - repro.c 
.file   "repro.c"
.text
Segmentation fault (core dumped)