Source: uwsgi Version: 2.0.28-8 Severity: important Tags: patch upstream X-Debbugs-Cc: debian-glibc@lists.debian.org User: debian-glibc@lists.debian.org Usertags: glibc2.41 dlopen-executable-stack Control: affects -1 uwsgi-plugin-pypy Control: forwarded -1 https://github.com/unbit/uwsgi/issues/2436
Dear maintainer, Starting with glibc 2.41, the dlopen and dlmopen functions no longer make the stack executable if a shared library requires it and instead just fail. This change aims to improve security, as the previous behaviour was used as a vector for RCE (CVE-2023-38408). Unfortunately the uwsgi-plugin-pypy package provides an extension for uwsgi which requires an executable stack. This can be seen as a warning in the build log [1]: | make[1]: Entering directory '/build/reproducible-path/uwsgi-plugin-pypy-0.0.2' | cp -ar /usr/src/uwsgi/plugins/pypy /build/reproducible-path/uwsgi-plugin-pypy-0.0.2/ | uwsgi --build-plugin "pypy pypy3" | /usr/bin/ld: warning: pypy/pypy_setup.py.o: missing .note.GNU-stack section implies executable stack | /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker | *** uWSGI building and linking plugin from pypy *** | ld -r -b binary -o pypy/pypy_setup.py.o pypy/pypy_setup.py | objcopy --redefine-sym _binary_pypy_pypy_setup_py_start=_uwsgi_pypy_setup_start pypy/pypy_setup.py.o | objcopy --redefine-sym _binary_pypy_pypy_setup_py_end=_uwsgi_pypy_setup_end pypy/pypy_setup.py.o | x86_64-linux-gnu-gcc -fPIC -shared -o pypy3_plugin.so -I. -O2 -I. -Wall -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/reproducible-path/uwsgi-2.0.28=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wformat-signedness -DUWSGI_HAS_IFADDRS -DUWSGI_ZLIB -DUWSGI_LOCK_USE_MUTEX -DUWSGI_EVENT_USE_EPOLL -DUWSGI_EVENT_TIMER_USE_TIMERFD -DUWSGI_EVENT_FILEMONITOR_USE_INOTIFY -DUWSGI_PCRE2 -DUWSGI_ROUTING -DUWSGI_CAP -DUWSGI_UUID -DUWSGI_VERSION="\"2.0.28-debian\"" -DUWSGI_VERSION_BASE="2" -DUWSGI_VERSION_MAJOR="0" -DUWSGI_VERSION_MINOR="28" -DUWSGI_VERSION_REVISION="0" -DUWSGI_VERSION_CUSTOM="\"debian\"" -DUWSGI_YAML -DUWSGI_LIBYAML -I/usr/include/yajl -DUWSGI_JSON -DUWSGI_JSON_YAJL -DUWSGI_SSL -I/usr/include/libxml2 -DUWSGI_XML -DUWSGI_XML_LIBXML2 -DUWSGI_PLUGIN_DIR="\"/usr/lib/uwsgi/plugins\"" -g -O2 -ffile-prefix-map=/build/reproducible-path/uwsgi-plugin-pypy-0.0.2=. -fstack-protector-strong -fstack-clash-protection -fcf-protection -I.uwsgi_plugins_builder/ -Dpypy_plugin=pypy3_plugin pypy/pypy_plugin.c pypy/pypy_setup.py.o -Wl,-z,relro | build time: 0 seconds | *** pypy3 plugin built and available in pypy3_plugin.so *** | make[1]: Leaving directory '/build/reproducible-path/uwsgi-plugin-pypy-0.0.2' The full build log is for instance available here: https://buildd.debian.org/status/fetch.php?pkg=uwsgi-plugin-pypy&arch=amd64&ver=0.0.2&stamp=1737808166&raw=0 With glibc 2.41, this plugin won't be loadable anymore. While the toolchain default to non-executable stack, uwsgi-plugin-pypy uses a custom ld command to embed code into the binary, which marks the resulting binary as requiring stack. This can be fixed by passing -z noexecstack to the ld command, as in the following patch available in the upstream bug tracker: https://github.com/unbit/uwsgi/issues/2436 Regards Aurelien
