20260320 builds seem to have executable-stack set on python shared library

[bersbersbers]

I must admit I don't exactly know what the above means, but I encountered pyinstaller errors (copied below) which were traced back to apparent changes in these Python builds:

My first hypothesis is thus https://github.com/astral-sh/python-build-standalone/releases/tag/20260320.

This indeed seems to be the case.

The builds in this release seem to have executable-stack set on python shared library, which can refuse to be loaded on sufficiently hardened systems (e.g., by SELinux).

$ wget https://github.com/astral-sh/python-build-standalone/releases/download/20260320/cpython-3.14.3+20260320-x86_64-unknown-linux-gnu-install_only.tar.gz
$ tar xvf cpython-3.14.3+20260320-x86_64-unknown-linux-gnu-install_only.tar.gz
$ execstack -q python/lib/libpython3.14.so
X python/lib/libpython3.14.so

vs. previous release:

$ wget https://github.com/astral-sh/python-build-standalone/releases/download/20260310/cpython-3.14.3+20260310-x86_64-unknown-linux-gnu-install_only.tar.gz
$ tar xvf cpython-3.14.3+20260310-x86_64-unknown-linux-gnu-install_only.tar.gz
$ execstack -q python/lib/libpython3.14.so
- python/lib/libpython3.14.so

As their python interpreter is not linked against the shared library (it's one of those builds where executable is statically linked against python shared library, and the latter is provided only for embedders, such as PyInstaller), it is not directly affected by this issue; and so I imagine it is easy for a problem like this to go unnoticed on their side.

Originally posted by @rokm in #9413

[indygreg]

I don't recall an obvious change that would cause this. I wonder if the LLVM 22 upgrade caused this.

[geofft]

Note that there was a previous report of an executable stack at #956 due to BOLT, which we didn't yet resolve... I'm surprised that 202060310 is not affected. Maybe these are two different problems. (As I mentioned in that thread, my hypothesis for the actual thing falsely causing a request for an executable stack is OpenSSL's assembly code.)

While we figure this out, a bad workaround (bad both because it's annoying and because it makes any buffer-overflow vulnerabilities more dangerous) might be setting the environment variable GLIBC_TUNABLES=glibc.rtld.execstack=2, which should force an executable stack on all programs that are run, allowing them to load libraries that request an executable stack. There is a relatively recent change in glibc to disallow binaries that didn't request an executable stack from loading libraries that do request it, but this broke some number of very old games or something so they added this workaround.

[bersbersbers]

a bad workaround [...] might be setting the environment variable GLIBC_TUNABLES=glibc.rtld.execstack=2

This does indeed make at least my CI tests pass - thanks!

[williballenthin]

For those using uv to invoke PyInstaller to build executables (that subsequently pull in python-build-standalone interpreters), I found that pinning uv to 0.10.6 uses python-build-standalone release 20260310 that does not have this regression.

[owquresh]

Happening with me as well, GLIBC_TUNABLES=glibc.rtld.execstack=2 worked for me as temp fix.

[jjhelmus]

The 20260320 build logs include this warning a few different times:

/tools/host/bin/ld: warning: libcrypto-lib-x86_64-gf2m.o: missing .note.GNU-stack section implies executable stack

I was not able to find this warning in the 20260310 build log.

What is strange is that this object is assembled with --noexecstack

2026-03-20T00:22:50.4854223Z openssl-3.5> clang -fPIC -pthread -m64 -Wa,--noexecstack -Qunused-arguments -Wall -O3 -O3 -fvisibility=hidden -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdebug-default-version=4 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/etc/ssl\"" -DENGINESDIR="\"/tools/deps/lib/engines-3\"" -DMODULESDIR="\"/tools/deps/lib/ossl-modules\"" -DOPENSSL_BUILDING_OPENSSL -DNDEBUG  -c -o crypto/bn/libcrypto-lib-x86_64-gf2m.o crypto/bn/x86_64-gf2m.s

[jjhelmus]

From llvm/llvm-project#186004 it seems as if llvm 22's assembler does not emit a .note.GNU-stack section when -Wa,--noexecstack is passed.

I'm working out a work around to this bug.