GNU C Library Lands Workaround After Breaking Various Steam Games, Discord & Other Apps
([GNU] 3 Hours Ago
Glibc Workaround For Executable Stack)
- Reference: 0001539512
- News link: https://www.phoronix.com/news/Glibc-WA-Steam-Exec-Stack
- Source link:
The release of the [1]GNU C Library 2.41 at the end of January ended up inadvertently breaking some Steam games, Discord, Julia, MATLAB, and other select user-space software. A workaround was merged today for Glibc to workaround the problem.
In early February a [2]Sourceware.org bug report was filed by Arch Linux developers over Glibc 2.41's dlopen / execstack handling breaking various apps:
"We over at Arch Linux have a received a few regression reports about various downstream projects impacted by the "dlopen and dlmopen no longer make the stack executable if a shared library requires it" change that was mentioned in the 2.41 release announcement...It's mainly closed source apps like "discord", some Steam games, but also "julia" language and possibly a few others... This also affects Mono for 32-bit systems in particular."
The Arch Linux crew also tracked down the problem to [3]this patch that is part of Glibc 2.41 for trying to improve executable stack handling.
Two months and one day after that initial bug report, a workaround was merged to Glibc Git. [4]This commit today to the mainline GNU C Library codebase extends the "glibc.rtld.execstack" tunable to force an executable stack. The commit summarizes:
"elf: Extend glibc.rtld.execstack tunable to force executable stack (BZ 32653)
From the bug report, multiple programs still require to dlopen shared libraries with either missing PT_GNU_STACK or with the executable bit set. Although, in some cases, it seems to be a hard-craft assembly source without the required .note.GNU-stack marking (so the static linker is forced to set the stack executable if the ABI requires it), other cases seem that the library uses trampolines.
Unfortunately, READ_IMPLIES_EXEC is not an option since on some ABIs (x86_64), the kernel clears the bit, making it unsupported. To avoid reinstating the broken code that changes stack permission on dlopen (0ca8785a28), this patch extends the glibc.rtld.execstack tunable to allow an option to force an executable stack at the program startup.
The tunable is a security issue because it defeats the PT_GNU_STACK hardening. It has the slight advantage of making it explicit by the caller, and, as for other tunables, this is disabled for setuid binaries. A tunable also allows us to eventually remove it, but from previous experiences, it would require some time.
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu."
So with this newly-merged code via the glibc.rtld.execstack tunable is at least a workaround for those experiencing broken apps on Glibc 2.41. This is considered just as a compatibility mode to allow programs requiring an executable stack through dynamically loaded shared libraries but otherwise is considered a security issue.
[1] https://www.phoronix.com/news/GNU-C-Library-glibc-2.41
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=32653
[3] https://sourceware.org/pipermail/libc-alpha/2024-December/163146.html
[4] https://sourceware.org/git/?p=glibc.git;a=commit;h=12a497c716f0a06be5946cabb8c3ec22a079771e
In early February a [2]Sourceware.org bug report was filed by Arch Linux developers over Glibc 2.41's dlopen / execstack handling breaking various apps:
"We over at Arch Linux have a received a few regression reports about various downstream projects impacted by the "dlopen and dlmopen no longer make the stack executable if a shared library requires it" change that was mentioned in the 2.41 release announcement...It's mainly closed source apps like "discord", some Steam games, but also "julia" language and possibly a few others... This also affects Mono for 32-bit systems in particular."
The Arch Linux crew also tracked down the problem to [3]this patch that is part of Glibc 2.41 for trying to improve executable stack handling.
Two months and one day after that initial bug report, a workaround was merged to Glibc Git. [4]This commit today to the mainline GNU C Library codebase extends the "glibc.rtld.execstack" tunable to force an executable stack. The commit summarizes:
"elf: Extend glibc.rtld.execstack tunable to force executable stack (BZ 32653)
From the bug report, multiple programs still require to dlopen shared libraries with either missing PT_GNU_STACK or with the executable bit set. Although, in some cases, it seems to be a hard-craft assembly source without the required .note.GNU-stack marking (so the static linker is forced to set the stack executable if the ABI requires it), other cases seem that the library uses trampolines.
Unfortunately, READ_IMPLIES_EXEC is not an option since on some ABIs (x86_64), the kernel clears the bit, making it unsupported. To avoid reinstating the broken code that changes stack permission on dlopen (0ca8785a28), this patch extends the glibc.rtld.execstack tunable to allow an option to force an executable stack at the program startup.
The tunable is a security issue because it defeats the PT_GNU_STACK hardening. It has the slight advantage of making it explicit by the caller, and, as for other tunables, this is disabled for setuid binaries. A tunable also allows us to eventually remove it, but from previous experiences, it would require some time.
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu."
So with this newly-merged code via the glibc.rtld.execstack tunable is at least a workaround for those experiencing broken apps on Glibc 2.41. This is considered just as a compatibility mode to allow programs requiring an executable stack through dynamically loaded shared libraries but otherwise is considered a security issue.
[1] https://www.phoronix.com/news/GNU-C-Library-glibc-2.41
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=32653
[3] https://sourceware.org/pipermail/libc-alpha/2024-December/163146.html
[4] https://sourceware.org/git/?p=glibc.git;a=commit;h=12a497c716f0a06be5946cabb8c3ec22a079771e
Quackdoc