Hi David, Thanks for the clarification and the link to the Microsoft article.
After compiling and running the "exploit", I couldn't really see how this was exploitable because it was all running as the same user. The same thing could be done with a fork/exec, or just exec. The Microsoft article was a good read that clarified my impressions. Cheers, Steve W. On January 15, 2026 8:03:48 p.m. PST, David Higgs <[email protected]> wrote: >On Thu, Jan 15, 2026 at 2:28 PM <[email protected]> wrote: > >> It looks like the author of these has posted an updated POC of the W^X >> break script since the start of this thread. >> >> Here: >> https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/107#note_47812 >> >> Quoting, they say this: >> >> "I have seen on openbsd-misc that people are rightfully claiming this >> break does not work on OpenBSD due to pinsyscalls. That said, this is only >> because I was lazy when writing the poc, this break has otherwise nothing >> to do with pinsyscalls. Also note this break works regardless of whether >> the executable memory was mapped MAP_PRIVATE or MAP_SHARED. Below is an >> update poc that pops a shell despite pinsyscalls on OpenBSD using a simple >> libc trampoline" >> >> I can also confirm that this works as they say. > > >The first, previously-linked example does not make any syscalls between the >two stack pivots. MAP_STACK is enforced at the kernel syscall boundary. >Note the "exploit" didn't work when it made a printf (write) call after >only one stack pivot. > >The second example demonstrates lazy-loading of file-backed mmap content. >Pinsyscalls is not involved because all syscalls are still made through >libc. Note the file is truncated before the mmap. What do you think is >present in the mmap'd buffer before the write+close? > >There is no privilege escalation in either case. The burglar is already >inside the house. >https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 > >--david
