Bug 280868 - sysutils/screen - stack overflow detected; terminated
Summary: sysutils/screen - stack overflow detected; terminated
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: arm64 Any
: --- Affects Only Me
Assignee: Cy Schubert
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-08-16 20:00 UTC by Andreas Schwarz
Modified: 2024-08-19 16:09 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (cy)


Attachments
Fix buffer overflow (off-by-one) in screen (1.12 KB, patch)
2024-08-19 15:29 UTC, Dimitry Andric
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Schwarz 2024-08-16 20:00:26 UTC
After upgrading sysutils/screen package from 4.9.1_2 to 4.9.1_3, screen will crash when starting a new session.

root@testelot:~ # pkg info screen
screen-4.9.1_3
Name           : screen
Version        : 4.9.1_3
Installed on   : Fri Aug 16 21:05:21 2024 CEST
Origin         : sysutils/screen
Architecture   : FreeBSD:13:aarch64
Prefix         : /usr/local
Categories     : sysutils
Licenses       : GPLv3
Maintainer     : cy@FreeBSD.org
WWW            : https://www.gnu.org/software/screen/
Comment        : Multi-screen window manager
[...]

root@testelot:~ # uname -a
FreeBSD testelot.schwarzes.net 13.3-RELEASE-p5 FreeBSD 13.3-RELEASE-p5 f5a50714b GENERIC arm64

root@testelot:~ # freebsd-version -kru
13.3-RELEASE-p5
13.3-RELEASE-p5
13.3-RELEASE-p5

Will happen also with 13.3-RELEASE-p4, previous screen version 4.9.1_2 (or just the screen-4.9.1 binary) 
work without any problems.

root@testelot:~ # screen -S test
[hangs]

ps axl
[...]
  0 1303 1140 3  20  0 13968  3640 pause    S+    0    0:00.03 screen -S test (screen-4.9.1)
  0 1304 1303 0  22  0     0     0 -        Z+    0    0:00.03 <defunct>

root@testelot:~ # tail -2 /var/log/messages
Aug 16 21:54:50 testelot SCREEN[1304]: stack overflow detected; terminated
Aug 16 21:54:50 testelot kernel: pid 1304 (screen-4.9.1), jid 0, uid 0: exited on signal 6 (core dumped)

root@testelot:~ # ll screen-4.9.1.core
-rw-------  1 root  wheel  11280384 Aug 16 21:54 screen-4.9.1.core
Comment 1 Cy Schubert freebsd_committer freebsd_triage 2024-08-16 20:23:35 UTC
I am unable to reproduce this problem locally. Tested on,

- FreeBSD 15-CURRENT installed by package from screen built in poudriere locally,
- FreeBSD 14.1-RELEASE-p1 with screen installed by package from freebsd.org,
- FreeBSD 13.3-RELEASE-p5 with screen installed by package from freebsd.org.

I tested screen-4.9.1_3.

This is a problem local to you. Please tell me more about your site, i.e.,

- whether screen was built by you or installed by package from freebsd.org
- other packages installed on the systems, especially the version of ncurses installed. List all packages, please.
- environment variables used at the time, especially $TERM. List all environment variables, please.
Comment 2 Andreas Schwarz 2024-08-16 20:55:48 UTC
screen (and the other packages) are installed as a package from the regular repository. System is a Raspberry Pi 4B with 8GB DRAM. 

root@testelot:~ # pkg info
abseil-20230125.3              Abseil Common Libraries (C++)
bash-5.2.26_1                  GNU Project's Bourne Again SHell
curl-8.8.0                     Command line tool and library for transferring data with URLs
e2fsprogs-libuuid-1.47.1       UUID library from e2fsprogs package
expat-2.6.2                    XML 1.0 parser written in C
fdupes-2.3.1,1                 Program for identifying or deleting duplicate files
fusefs-exfat-1.4.0_1           Full-featured exFAT FS implementation as a FUSE module
fusefs-libs-2.9.9_2            FUSE allows filesystem implementation in userspace
fusefs-ntfs-2022.10.3_1        Mount NTFS partitions (read/write) and disk images
gettext-runtime-0.22.5         GNU gettext runtime libraries and programs
gitup-0.99                     Minimalist, dependency-free program to clone/pull Git repositories
gnupg1-1.4.23_4                The GNU Privacy Guard (minimalist "classic" version)
id3lib-3.8.3.20240114          Library for manipulating ID3v1/v1.1 and ID3v2 tags
id3v2-0.1.12                   Command line id3v2 tag editor
indexinfo-0.3.1                Utility to regenerate the GNU info page index
iperf-2.2.0                    Tool to measure maximum TCP and UDP bandwidth
jhead-3.08                     EXIF JPEG header manipulation tool
jpeg-turbo-3.0.3               SIMD-accelerated JPEG codec which replaces libjpeg
jsoncpp-1.9.5                  JSON reader and writer library for C++
lftp-4.9.2_1                   Shell-like command-line FTP client
libiconv-1.17_1                Character set conversion library
libidn2-2.3.7                  Implementation of IDNA2008 internationalized domain names
liblz4-1.9.4_1,1               LZ4 compression library, lossless and very fast
libnghttp2-1.62.1              HTTP/2.0 C Library
libpsl-0.21.5_1                C library to handle the Public Suffix List
libssh2-1.11.0_1,3             Library implementing the SSH2 protocol
libublio-20070103_3            User space caching library
libunistring-1.2               Unicode string library
p5-Cpanel-JSON-XS-4.38         JSON::XS for Cpanel, fast and correct serialising
p7zip-16.02_3                  File archiver with high compression ratio
pcre2-10.43                    Perl Compatible Regular Expressions library, version 2
perl5-5.36.3_1                 Practical Extraction and Report Language
pkg-1.21.3                     Package manager
protobuf-24.4,1                Data interchange format library
readline-8.2.10                Library for editing command lines as they are typed
rsync-3.3.0                    Network file distribution/synchronization utility
screen-4.9.1_3                 Multi-screen window manager
unrar-7.01,6                   Extract, view & test RAR archives
xxhash-0.8.2_1                 Extremely fast non-cryptographic hash algorithm
zstd-1.5.6                     Fast real-time compression algorithm

root@testelot:~ # set
BASH=/usr/local/bin/bash
BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:globasciiranges:globskipdots:hostcomplete:interactive_comments:login_shell:patsub_replacement:progcomp:promptvars:sourcepath
BASH_ALIASES=()
BASH_ARGC=([0]="0")
BASH_ARGV=()
BASH_CMDS=()
BASH_LINENO=()
BASH_LOADABLES_PATH=/usr/local/lib/bash:/usr/lib/bash:/opt/local/lib/bash:/usr/pkg/lib/bash:/opt/pkg/lib/bash:.
BASH_SOURCE=()
BASH_VERSINFO=([0]="5" [1]="2" [2]="26" [3]="1" [4]="release" [5]="aarch64-portbld-freebsd13.2")
BASH_VERSION='5.2.26(1)-release'
BLOCKSIZE=K
COLUMNS=130
DIRSTACK=()
EDITOR=vi
EUID=0
GROUPS=()
HISTCONTROL=ignorespace:ignoredups:erasedups
HISTFILE=/root/.bash_history
HISTFILESIZE=8192
HISTSIZE=8192
HOME=/root
HOSTNAME=testelot.schwarzes.net
HOSTTYPE=aarch64
IFS=$' \t\n'
IGNOREEOF=10
LANG=C.UTF-8
LINES=40
LOGNAME=root
MACHTYPE=aarch64-portbld-freebsd13.2
MAIL=/var/mail/root
MAILCHECK=60
MM_CHARSET=UTF-8
OLDPWD=/usr/src
OPTERR=1
OPTIND=1
OSTYPE=freebsd13.2
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
PIPESTATUS=([0]="0")
PPID=1138
PS1='\u@\h:\w \$ '
PS2='> '
PS4='+ '
PWD=/root
SHELL=/usr/local/bin/bash
SHELLOPTS=braceexpand:hashall:histexpand:history:ignoreeof:interactive-comments:monitor:notify:vi
SHLVL=1
SSH_AUTH_SOCK=/tmp/ssh-VfFUU2YbXj/agent.1138
SSH_CLIENT='172.21.28.113 49872 22'
SSH_CONNECTION='172.21.28.113 49872 172.21.28.39 22'
SSH_TTY=/dev/pts/0
TERM=xterm
UID=0
USER=root
VISUAL=vi
_=info
Comment 3 Cy Schubert freebsd_committer freebsd_triage 2024-08-16 21:11:28 UTC
Hmm. This could be a problem on arm64 only then.

What is the output of sysctl -a | grep aslr ?

Testing on the FreeBSD 13aarch64 system (13.3-STABLE) available to developers, I cannot reproduce the problem there with 4.9.1_3. ASLR is enabled there so I doubt this would be a problem but let's look at this first. If ASLR is enabled, try disabling it, as some apps do have problems with ASLR, specifically the stack gap (a randomized gap between the stack and the upper limit of virtual memory).
Comment 4 Andreas Schwarz 2024-08-16 21:13:22 UTC
root@testelot:~ # sysctl -a | grep aslr
kern.elf32.aslr.stack: 0
kern.elf32.aslr.honor_sbrk: 0
kern.elf32.aslr.pie_enable: 0
kern.elf32.aslr.enable: 0
kern.elf64.aslr.stack: 1
kern.elf64.aslr.honor_sbrk: 0
kern.elf64.aslr.pie_enable: 1
kern.elf64.aslr.enable: 1
vm.aslr_restarts: 0
Comment 5 Andreas Schwarz 2024-08-16 21:19:36 UTC
Disabling kern.elf64.aslr.enable did not help, problem is still there.
Comment 6 Cy Schubert freebsd_committer freebsd_triage 2024-08-16 22:10:41 UTC
First thought:

None of this makes any sense because 4.9.1_3 was only a port revision bump to force a rebuild after src 21817992b33 (an ncurses 6.5 upgrade in 15-CURRENT).

And 4.9.1_2 moved the man page from /usr/local/man to /usr/local/share/man. So the latest version is the same as 4.9.1_1 and 4.9.1_2.

4.9.1_1 ignores legacy pty, because some users disable legacy pty.

The binaries built by 4.9.1_1, 4.9.1_2, and 4.9.1_3 are exactly the same as each other. 

Given all this, are you sure 4.9.1_2 exhibited no problem. If you are sure then this is entirely a local problem at your site and we need to discover what is different about your machines.

Next thought:

As you have a core file, let's get a backtrace.
Comment 7 Andreas Schwarz 2024-08-16 22:56:49 UTC
Sorry, but the binaries are not "exactly the same", they differ. Please download the packages 
and check by yourself.

# binary from screen-4.9.1_3

root@testelot:~ # ll /usr/local/bin/screen-4.9.1
-r-sr-xr-x  1 root  wheel  414056 Jul 17 19:34 /usr/local/bin/screen-4.9.1

root@testelot:~ # sha256sum /usr/local/bin/screen-4.9.1
b7c04cb19991c445d0f09a0bd682c1eb16b152458e60e504591e1d1969b0edd0  /usr/local/bin/screen-4.9.1


# binary from screen-4.9.1_2

root@ozelot:~ # ll /usr/local/bin/screen-4.9.1
-r-sr-xr-x  1 root  wheel  403800 Aug 16 22:02 /usr/local/bin/screen-4.9.1

root@ozelot:~ # sha256sum /usr/local/bin/screen-4.9.1
8421dc727bcefe305eecf5c32960a53ee733d6516e89ad1d9e82a3ce16a3af81  /usr/local/bin/screen-4.9.1


As I wrote, when replacing the screen-4.9.1_3 binary with the one which is included in screen-4.9.1_2
all works fine.


I did also an upgrade at another machine before open the report, to be sure that it's caused 
by the screen-4.9.1_3 package.


root@ozelot:~ #  pkg remove screen
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
        screen: 4.9.1_2

Number of packages to be removed: 1

Proceed with deinstalling packages? [y/N]: y
[1/1] Deinstalling screen-4.9.1_2...
[1/1] Deleting files for screen-4.9.1_2: 100%
root@ozelot:~ #

root@ozelot:~ # pkg install screen
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        screen: 4.9.1_3

Number of packages to be installed: 1

460 KiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching screen-4.9.1_3.pkg: 100%  460 KiB 471.3kB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Installing screen-4.9.1_3...
[1/1] Extracting screen-4.9.1_3: 100%
=====
Message from screen-4.9.1_3:

--
As of GNU Screen 4.4.0:

Note that there was fix to screen message structure field
responsible for $TERM handling, making it impossible
to attach to older versions.
Comment 8 Andreas Schwarz 2024-08-16 23:34:43 UTC
root@testelot:~ # gdb /usr/local/bin/screen-4.9.1 screen-4.9.1.core
GNU gdb (GDB) 14.1 [GDB v14.1 for FreeBSD]
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-portbld-freebsd13.3".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/screen-4.9.1...
(No debugging symbols found in /usr/local/bin/screen-4.9.1)
[New LWP 100118]
Core was generated by `screen -S test'.
Program terminated with signal SIGABRT, Aborted.
Sent by kill() from pid 1289 and user 0.
#0  0x0000000040592b2c in kill () from /lib/libc.so.7
(gdb) bt
#0  0x0000000040592b2c in kill () from /lib/libc.so.7
#1  0x0000000040594ba8 in ?? () from /lib/libc.so.7
#2  0x0000000040594b24 in __stack_chk_fail () from /lib/libc.so.7
#3  0x0000000000247430 in ?? ()
#4  0x00000000002453c8 in ?? ()
#5  0x0000000000226718 in ?? ()
#6  0x0000000000224a2c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Comment 9 Cy Schubert freebsd_committer freebsd_triage 2024-08-16 23:41:08 UTC
(In reply to Andreas Schwarz from comment #7)

What is different between _2 and _3 are dependencies. The screen sources have not changed for 13-REL.
Comment 10 Cy Schubert freebsd_committer freebsd_triage 2024-08-16 23:48:06 UTC
(In reply to Andreas Schwarz from comment #8)

Without symbols there is no way to know where we are in the backtrace.

I don't have root on ref13-aarch64; building the necessary dependencies is impossible. I'll have to rely on you to build a debugging binary to test.

Please,

cd /usr/ports/sysutils/screen
make -DWITH_DEBUG
./work/stage/usr/local/bin/screen-4.9.1

Then after it crashes,

gdb ./work/stage/usr/local/bin/screen-4.9.1 screen.core
bt
Comment 11 Andreas Schwarz 2024-08-17 01:11:21 UTC
Build the port with debug information.

Core was generated by `screen -S test'.
Program terminated with signal SIGABRT, Aborted.
Sent by kill() from pid 10377 and user 0.
#0  0x00000000405cdb2c in kill () from /lib/libc.so.7
(gdb) bt
#0  0x00000000405cdb2c in kill () from /lib/libc.so.7
#1  0x00000000405cfba8 in ?? () from /lib/libc.so.7
#2  0x00000000405cfb24 in __stack_chk_fail () from /lib/libc.so.7
#3  0x0000000000260ed8 in MakeTermcap (aflag=0) at termcap.c:1125
#4  0x000000000025efe4 in InitTermcap (wi=0, he=0) at termcap.c:483
#5  0x0000000000226db4 in main (ac=0, av=0xffffffffea60) at screen.c:1390
(gdb)
Comment 12 Cy Schubert freebsd_committer freebsd_triage 2024-08-17 01:41:16 UTC
Certainly looks like a compiler bug.

Can you build with,

make USE_GCC=13

And run the same test.
Comment 13 Andreas Schwarz 2024-08-17 02:46:41 UTC
Ok, when building the port with gcc13 there is no problem. 

So, it seems it's something with clang build environment in combination with 13.3, because the working screen 4.9.1_2 (quarterly) package 
was build with the previous 13.2 environment.

-> 4.9.1_2/screen-4.9.1: setuid ELF 64-bit LSB executable, ARM aarch64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.2, FreeBSD-style, stripped

-> 4.9.1_3/screen-4.9.1: setuid ELF 64-bit LSB executable, ARM aarch64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.3, FreeBSD-style, stripped


I'm really sure, that this is not a local problem, but it's too rare, so there are no other reports (yet). Maybe it's related only to arm64.
Comment 14 Cy Schubert freebsd_committer freebsd_triage 2024-08-17 04:48:43 UTC
(In reply to Andreas Schwarz from comment #13)

Can you provide uname -a output, please? I'm taking time tonight to have a quick look at the port. We already have the following in the port's Makefile:

.if ${ARCH} == armv6 || ${ARCH} == armv7 || ${ARCH} == i386 || \
    ${ARCH:Mpowerpc*}
SSP_CFLAGS?=    -fno-stack-protector
.endif 

I'm thinking we need to add aarch64 or whatever is reported by uname at your site.
Comment 15 Andreas Schwarz 2024-08-17 11:37:29 UTC
root@testelot:~ # uname -a
FreeBSD testelot.schwarzes.net 13.3-RELEASE-p5 FreeBSD 13.3-RELEASE-p5 f5a50714b GENERIC arm64
Comment 16 Andreas Schwarz 2024-08-17 15:28:19 UTC
MACHINE_ARCH is "aarch64", if added this to the Makefile to disable the stack protector. This was successful and clang build was functional again.

root@testelot:~ # uname -p
aarch64

--- Makefile.orig       2024-08-17 17:25:59.274992000 +0200
+++ Makefile    2024-08-17 17:27:08.776671000 +0200
@@ -52,7 +52,7 @@

 .include <bsd.port.options.mk>

-.if ${ARCH} == armv6 || ${ARCH} == armv7 || ${ARCH} == i386 || \
+.if ${ARCH} == armv6 || ${ARCH} == armv7 || ${ARCH} == i386 || ${ARCH} == aarch64 || \
     ${ARCH:Mpowerpc*}
 SSP_CFLAGS?=   -fno-stack-protector
 .endif
Comment 17 Cy Schubert freebsd_committer freebsd_triage 2024-08-18 12:08:13 UTC
(In reply to Andreas Schwarz from comment #16)

Thanks for confirming my hunch.
Comment 18 commit-hook freebsd_committer freebsd_triage 2024-08-18 13:12:01 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=92b0c9cdbef548739d6209165c3e1731761d010d

commit 92b0c9cdbef548739d6209165c3e1731761d010d
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2024-08-18 13:08:04 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2024-08-18 13:11:28 +0000

    sysutils/screen*: Fix stack overflow detected on aarch64

    Fix,

    SCREEN[1304]: stack overflow detected; terminated
    kernel: pid 1304 (screen-4.9.1), jid 0, uid 0: exited on signal 6 (core dumped)

    PR:             280868
    Tested by:      Andreas Schwarz <bugs.freebsd.asc@schwarzes.net>
    MFH:            2024Q3

 sysutils/screen-devel/Makefile | 4 ++--
 sysutils/screen/Makefile       | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
Comment 19 commit-hook freebsd_committer freebsd_triage 2024-08-18 13:17:05 UTC
A commit in branch 2024Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=b11a3e9ca791495762beb441817267d1906f6725

commit b11a3e9ca791495762beb441817267d1906f6725
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2024-08-18 13:08:04 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2024-08-18 13:15:54 +0000

    sysutils/screen*: Fix stack overflow detected on aarch64

    Fix,

    SCREEN[1304]: stack overflow detected; terminated
    kernel: pid 1304 (screen-4.9.1), jid 0, uid 0: exited on signal 6 (core dumped)

    PR:             280868
    Tested by:      Andreas Schwarz <bugs.freebsd.asc@schwarzes.net>

    (cherry picked from commit 92b0c9cdbef548739d6209165c3e1731761d010d)

 sysutils/screen-devel/Makefile | 4 ++--
 sysutils/screen/Makefile       | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
Comment 20 Cy Schubert freebsd_committer freebsd_triage 2024-08-18 13:18:26 UTC
Fixed.
Comment 21 commit-hook freebsd_committer freebsd_triage 2024-08-18 13:25:06 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=41881861905e2368c69ea9596c1673f1e56bf5aa

commit 41881861905e2368c69ea9596c1673f1e56bf5aa
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2024-08-18 13:20:27 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2024-08-18 13:24:16 +0000

    sysutils/screen*: Bump PORTREVISION for runtime fix

    92b0c9cdbef5 fixed a runtime issue. A PORTREVISION bump is required.

    PR:     280868
    MFH:    2024Q4

 sysutils/screen-devel/Makefile | 1 +
 sysutils/screen/Makefile       | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
Comment 22 commit-hook freebsd_committer freebsd_triage 2024-08-18 13:26:07 UTC
A commit in branch 2024Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=c8f957c25d56334e9a1a517e3af7e2854f22c1db

commit c8f957c25d56334e9a1a517e3af7e2854f22c1db
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2024-08-18 13:20:27 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2024-08-18 13:24:58 +0000

    sysutils/screen*: Bump PORTREVISION for runtime fix

    92b0c9cdbef5 fixed a runtime issue. A PORTREVISION bump is required.

    PR:     280868

    (cherry picked from commit 41881861905e2368c69ea9596c1673f1e56bf5aa)

 sysutils/screen-devel/Makefile | 1 +
 sysutils/screen/Makefile       | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
Comment 23 Dimitry Andric freebsd_committer freebsd_triage 2024-08-19 15:29:26 UTC
Created attachment 252920 [details]
Fix buffer overflow (off-by-one) in screen

Note that this isn't a compiler bug, it is a buffer overflow in screen:

acls.c:95:49: runtime error: applying zero offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior acls.c:95:49
acls.c:95:84: runtime error: applying non-zero offset 1 to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior acls.c:95:84
=================================================================
==21713==ERROR: AddressSanitizer: stack-buffer-overflow on address 0xffffffff60ff at pc 0x0000002faecc bp 0xffffffff5bd0 sp 0xffffffff53c0
WRITE of size 1024 at 0xffffffff60ff thread T0
    #0 0x2faec8 in strncpy /wrkdirs/usr/ports/devel/llvm18/work-default/llvm-project-18.1.8.src/compiler-rt/lib/asan/asan_interceptors.cpp:605:5
    #1 0x4089586c in tgetent_sp /usr/src/contrib/ncurses/ncurses/tinfo/lib_termcap.c:217:2
    #2 0x699ee8 in e_tgetent /home/dim/screen/src/termcap.c:1057:6
    #3 0x67cdb0 in InitTermcap /home/dim/screen/src/termcap.c:98:26
    #4 0x343860 in main /home/dim/screen/src/screen.c:1031:7

Address 0xffffffff60ff is located in stack of thread T0 at offset 1055 in frame
    #0 0x67ca58 in InitTermcap /home/dim/screen/src/termcap.c:91

  This frame has 2 object(s):
    [32, 1055) 'tbuf' (line 94)
    [1184, 1192) 'tp' (line 94) <== Memory access at offset 1055 partially underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /usr/src/contrib/ncurses/ncurses/tinfo/lib_termcap.c:217:2 in tgetent_sp
Shadow bytes around the buggy address:
  0xffffffff5e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0xffffffff5e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0xffffffff5f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0xffffffff5f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0xffffffff6000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0xffffffff6080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[07]
  0xffffffff6100: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
  0xffffffff6180: 00 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0xffffffff6200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0xffffffff6280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0xffffffff6300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==21713==ABORTING

The strncpy() it calls in contrib/ncurses/ncurses/tinfo/lib_termcap.c is an atrocious hack added by Peter Wemm way back in 1999:
https://cgit.freebsd.org/src/commit/?id=c8b9c85ee5bb57d4c11afdc2e3f3109ba32a8846

Note that screen has in os.h:

#ifndef TERMCAP_BUFSIZE
# define TERMCAP_BUFSIZE 1023
#endif

I.e. it's doing a strncpy of 1024 bytes into a 1023 byte buffer: off-by-one. Depending on all kinds of things, this can be fatal or not, and a good stack smash detection should catch it.

This is also the reason why it only appears on certain platforms and configurations: not everywhere is the _nc_termcap[] variable this large.

Also, lib/ncurses/ncurses/termcap.c where it originates has been deleted in https://cgit.freebsd.org/src/commit/?id=61f66a1f4403fded9aae14d890ad96914a3c0bc1, so on -CURRENT this whole part of code will never be touched.
Comment 24 Cy Schubert freebsd_committer freebsd_triage 2024-08-19 15:40:47 UTC
(In reply to Dimitry Andric from comment #23)

Makes sense. Do you want to commit this or should I?
Comment 25 Cy Schubert freebsd_committer freebsd_triage 2024-08-19 15:45:17 UTC
This needs to be applied to screen-devel as well. I may as well commit it.
Comment 26 commit-hook freebsd_committer freebsd_triage 2024-08-19 16:06:24 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=1c7e0fd32c4ac92369dbdc15fb5abf048524a9b2

commit 1c7e0fd32c4ac92369dbdc15fb5abf048524a9b2
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2024-08-19 15:49:48 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2024-08-19 16:05:38 +0000

    sysutils/screen*: Fix off-by-one buffer overflow

    FreeBSD ncurses, as of c8b9c85ee5bb, does a strncpy() of 1024 bytes into
    a 1023 byte buffer supplied by screen. This section of code in ncurses
    was removed in 61f66a1f4403, and is not a problem since 14.0-RELEASE.
    But it is still a problem in 13-STABLE.

    Thank you to dim@ for detailed analysis and initial patch to
    sysutils/screen. The same patch is also applied to sysutils/screen-devel
    this commit.

    PR:             280868
    MFH:            2024Q3

 sysutils/screen-devel/Makefile         |  7 +------
 sysutils/screen-devel/files/patch-os.h | 13 +++++++++++--
 sysutils/screen/Makefile               |  7 +------
 sysutils/screen/files/patch-os.h       |  9 +++++++++
 4 files changed, 22 insertions(+), 14 deletions(-)
Comment 27 commit-hook freebsd_committer freebsd_triage 2024-08-19 16:09:26 UTC
A commit in branch 2024Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=5c23182d5fc90586b59c5312afb3e36d4edf389c

commit 5c23182d5fc90586b59c5312afb3e36d4edf389c
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2024-08-19 15:49:48 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2024-08-19 16:08:32 +0000

    sysutils/screen*: Fix off-by-one buffer overflow

    FreeBSD ncurses, as of c8b9c85ee5bb, does a strncpy() of 1024 bytes into
    a 1023 byte buffer supplied by screen. This section of code in ncurses
    was removed in 61f66a1f4403, and is not a problem since 14.0-RELEASE.
    But it is still a problem in 13-STABLE.

    Thank you to dim@ for detailed analysis and initial patch to
    sysutils/screen. The same patch is also applied to sysutils/screen-devel
    this commit.

    PR:             280868

    (cherry picked from commit 1c7e0fd32c4ac92369dbdc15fb5abf048524a9b2)

 sysutils/screen-devel/Makefile         |  7 +------
 sysutils/screen-devel/files/patch-os.h | 13 +++++++++++--
 sysutils/screen/Makefile               |  7 +------
 sysutils/screen/files/patch-os.h       |  9 +++++++++
 4 files changed, 22 insertions(+), 14 deletions(-)