Indeed, this is a very serious problem on other systems. Even more so than this article suggests. This has impacted portable versions of OpenSSH on several occasions, due to certain major PAM modules, meaning that sshd on Linux would always have a writable/executable stack.
The OpenBSD project has been fighting the ecosystem on this for a long time, there are no executable stacks on OpenBSD.
The pmap support appeared in subsequent commits for multiple platforms, almost 18 years ago, even before support the amd64 architecture landed in-tree in 2004. It had non-exec stacks from day 1.
Historically we didn't include a section in the binary indicating noexec stack, because that was the default.
The OpenBSD kernel and ld.so (runtime-linker) have always ignored PT_GNU_STACK. On other platforms, its absence is treated to assume an executable stack. The mupdf-x11 example in this article highlights that. The default should be a non-exec stack, but is instead treated like the NX bit. It's a fail open design.
If you compare OpenBSD against a modern Linux distro, you'll be surprised.
Similarly, macOS will enable NX unless you specify -allow_stack_execute to the linker when creating your program (fun fact: Apple apparently has a page on preventing buffer overflows at https://developer.apple.com/library/archive/documentation/Se...), and even that will be ignored on iOS or other OSes with code signing enforcement.
Probably the same (or worse) as Linux. IIRC FreeBSD still had executable stacks by default until at least 2016?
Edit: I give FreeBSD too much credit.
The kern.elf64.nxstack / kern.elf32.nxstack sysctls were introduced in FreeBSD 9.0, which is 0 by default. 1 enables PT_GNU_STACK behaviour. Apparently not implemented for all platforms. So you get to choose from executable stacks by default and the same nasty behaviour Linux has.
The OpenBSD project has been fighting the ecosystem on this for a long time, there are no executable stacks on OpenBSD.
https://github.com/openbsd/src/commit/32c3fa3f83422ae0dec73c...
The pmap support appeared in subsequent commits for multiple platforms, almost 18 years ago, even before support the amd64 architecture landed in-tree in 2004. It had non-exec stacks from day 1.
Historically we didn't include a section in the binary indicating noexec stack, because that was the default.
https://marc.info/?l=openbsd-cvs&m=149606868308439&w=2
The OpenBSD kernel and ld.so (runtime-linker) have always ignored PT_GNU_STACK. On other platforms, its absence is treated to assume an executable stack. The mupdf-x11 example in this article highlights that. The default should be a non-exec stack, but is instead treated like the NX bit. It's a fail open design.
If you compare OpenBSD against a modern Linux distro, you'll be surprised.