Re: Stack pivot, W^X break

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 <higgsd@gmail.com> wrote:

On Thu, Jan 15, 2026 at 2:28 PM <fro@disciples.com> 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