You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to the effectively empty huf_decompress_amd64.S on non amd64 architectures,
the empty assembly file is still significant, and causes libs to be built with an executable stack.
This triggers various security issues, most obvious being failure to boot on non x86_64 fedora systems,
due to systemd not loading as it sees the dependent libzstd.so.1 as a security issue (which it is).
Can confirm that today 2 of my arm 32-bit boards (armv6hl and armv7hnl) did not boot after upgrade of zstd to 1.5.1.
For reference:
a5f2c45528032ed20c33e0f8cd2c163a800a0017 is the first bad commit
commit a5f2c45528032ed20c33e0f8cd2c163a800a0017
Author: Nick Terrell <terrelln@fb.com>
Date: Fri Sep 17 11:43:04 2021 -0700
Huffman ASM
Apparently, even when the assembly file is empty (because
`ZSTD_ENABLE_ASM_X86_64_BMI2` is false), it still is marked as possibly
needing an executable stack and so the whole library is marked as such. This
commit applies a simple patch for this problem by moving the noexecstack
indication outside the macro guard.
This commit builds on facebook#2857.
This commit addresses facebook#2963.
…platforms
Without this, many systemd services, including journald and udevd fail to
start on non x86_64 platforms with:
"error while loading shared libraries: libzstd.so.1: cannot enable
executable stack as shared object requires: Operation not permitted"
See also: facebook/zstd#2963
Cherry-pick the relevant patches from upstream to fix this.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Due to the effectively empty huf_decompress_amd64.S on non amd64 architectures,
the empty assembly file is still significant, and causes libs to be built with an executable stack.
This triggers various security issues, most obvious being failure to boot on non x86_64 fedora systems,
due to systemd not loading as it sees the dependent libzstd.so.1 as a security issue (which it is).
There were a few solutions discussed at https://bugzilla.redhat.com/2035802
A possible fix may be just to move the "non executable stack" directive outside the ifdef in the huf_decompress_amd64.S file
The text was updated successfully, but these errors were encountered: