[Bug 258556] devel/llvm12: overwriting static memory

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 17 Sep 2021 10:41:42 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258556

            Bug ID: 258556
           Summary: devel/llvm12: overwriting static memory
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: brooks@FreeBSD.org
          Reporter: dinoex@FreeBSD.org
          Assignee: brooks@FreeBSD.org
             Flags: maintainer-feedback?(brooks@FreeBSD.org)

With OpenSSL from ports I build a new version of tinyfuge (5.1.1):
Sources: https://github.com/ingwarsw/tinyfugue

The compiled code fails on starting the SSL connection.

Output:
% Trying to connect to ap: XXXX:f840::42 8889.
% SSL: cert verify depth exceeded: allowed=0 actual=2
% SSL: cert verify error: err=22 'certificate chain too long' depth:2
cn:/C=US/O=Internet
    Security Research Group/CN=ISRG Root X1
% Intermediate connection to ap failed: SSL/lib: error:1416F086:SSL


While debugging with gcc the static memory of the application gets overwritten.
ssl_options is overwritten with bad data.

The code of the application seems fine, -Wall does not show any hints.
Once I enabled "-g" in CFLAGS the application runs.

Output:
% Trying to connect to ap: XXXX:f840::42 8889.
% SSL: chain: depth:2 cn:/C=US/O=Internet Security Research Group/CN=ISRG Root
X1
% SSL: chain: depth:1 cn:/C=US/O=Let's Encrypt/CN=R3
% SSL: chain: depth:0 cn:/CN=ap.XXXX.org
% SSL: cert verified: OK ret=0
% Connected to ap using cipher TLS_AES_256_GCM_SHA384.


I tested a few compilers:
clang version 10.0.1 (base)
clang version 12.0.1 (devel/llvm12)
gcc10 (FreeBSD Ports Collection) 10.3.0


The Problem happens with:
clang
clang12
clang -O1
clang12 -O1

The application runs with:
clang -g
clang -O0
clang12 -O0
gcc10 -O2
gcc10 -O3

The structure on FreeBSD 12.2 has an address of:
0x7fffffffe4c0  (fail)
0x7fffffffe340  (ok)
I guess there is something going wrong with the memory mapping.

-- 
You are receiving this mail because:
You are the assignee for the bug.