Experimental Physics and
Industrial Control System

Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> · Thu, 20 Jun 2024 13:42:56 -0700

On 6/20/24 00:07, Timo Korhonen via Tech-talk wrote:

...
"... Only activated when compiled with -O1 or higher."

Ah, my mistake.  My debug build was "-O0".  (and the glibc documentation[3] does not mention this)

With "-O1" the s1len argument[1][2] to __strncpy_chk() is not optimized away,
so that stack frame is more meaningful.

I guess my advice for troubleshooting the next occurrence will include
adding "OPT_CFLAGS_NO += -O1" to configure/CONFIG_SITE and rebuilding.

[1] https://urldefense.us/v3/__https://github.com/bminor/glibc/blob/da905bb706672c84130226bfff9de7d6ba1f0eb6/debug/strncpy_chk.c*L23C1-L23C14__;Iw!!G_uCfscf7eWS!fLFdio7gXAYHe7XXuSBEls_YLMUGAJgyzVCWLCwyFU3qjbvuGrndvfEfIf1_wAepl2CsuNpkJaBueVITSJhzixt4_w$

[2] https://urldefense.us/v3/__https://github.com/bminor/glibc/blob/da905bb706672c84130226bfff9de7d6ba1f0eb6/string/bits/string_fortified.h*L100-L101__;Iw!!G_uCfscf7eWS!fLFdio7gXAYHe7XXuSBEls_YLMUGAJgyzVCWLCwyFU3qjbvuGrndvfEfIf1_wAepl2CsuNpkJaBueVITSJgZnVyUbg$

[3] https://urldefense.us/v3/__https://www.gnu.org/software/libc/manual/html_node/Source-Fortification.html__;!!G_uCfscf7eWS!fLFdio7gXAYHe7XXuSBEls_YLMUGAJgyzVCWLCwyFU3qjbvuGrndvfEfIf1_wAepl2CsuNpkJaBueVITSJgDgXBLUA$

A little bit odd is that the page also says "First enabled as -D_FORTIFY_SOURCE=2 in Ubuntu 8.10 and updated to -D_FORITFY_SOURCE=3 in Ubuntu 24.04." Apparently the update was already applied in Ubuntu 22.04.

Timo

On 2024-06-20, 08:52, "Tech-talk on behalf of Jörn Dreyer via Tech-talk" <tech-talk-bounces at aps.anl.gov <mailto:tech-talk-bounces at aps.anl.gov> on behalf of tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>> wrote:

Hi Michael,

yes, you are right that the level of optimization plays a role wether the check triggers a fault or not.
At leas thats what the documentation of the _FORTIFY_SOURCE macro says.

Jörn

Am Donnerstag, 20. Juni 2024, 07:28:29 MESZ schrieb Michael Davidsaver via Tech-talk:

On 6/19/24 21:26, Michael Davidsaver wrote:

I see something like the following. All of the 'f's mean that GCC
is unable to track the sizes of the objects involved. I also don't
see a fault.

X test.LINR ptemp=ffffffffffffffff,ffffffffffffffff papChoice=ffffffffffffffff,ffffffffffffffff i=0

I spoke too soon. I can reproduce, but not with a -debug build.
So I guess '-O2' vs '-O3' plays some role?

X test.LINR ptemp=ffffffffffffffff,28 papChoice=ffffffffffffffff,ffffffffffffffff i=0
X test.LINR ptemp=ffffffffffffffff,0 papChoice=ffffffffffffffff,ffffffffffffffff i=1
*** buffer overflow detected ***: terminated

The inferred size of 'ptemp' is 28 bytes, which I can only assume comes from
this line.

ptemp = &(pdbr_enumStrs->strs[0][0]);

I don't understand why 28 and not 1, 30, or 30*40 ?

The first iteration steps past this.

ptemp += sizeof(pdbr_enumStrs->strs[0]);

This is certainly an odd way to iterate an array...

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System