Load ELF interpreter high so a low-loaded ET_EXEC's brk heap isn't capped by willportnoy · Pull Request #1023 · microsoft/litebox

Will Portnoy (willportnoy) · 2026-07-11T20:48:36Z

Cherry-pick of #985 (squash commit f5ad1f20) onto ulitebox.

Dynamically-linked ET_EXEC (non-PIE) binaries load at their low canonical vaddrs and grow their glibc brk heap upward from there, but the ELF interpreter was reserved at a fixed low offset directly above the main image — capping the heap, so a heap-heavy process (e.g. a bundled node) hit ENOMEM the moment it crossed that offset. This loads the interpreter at the top of the address space instead, mirroring how the kernel places ld.so for an ET_EXEC main and leaving the whole gap above the main image free for the heap; it is a no-op for PIE mains, whose interpreter already loads high.

…pped (#985) Dynamically-linked ET_EXEC (non-PIE) binaries load at their low canonical vaddrs and grow their glibc `brk` heap upward from there, but the ELF interpreter was reserved at a fixed low offset directly above the main image — capping the heap, so a heap-heavy process (e.g. a bundled `node`) hit `ENOMEM` the moment it crossed that offset. This loads the interpreter at the top of the address space instead, mirroring how the kernel places `ld.so` for an ET_EXEC main and leaving the whole gap above the main image free for the heap; it is a no-op for PIE mains, whose interpreter already loads high. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-12T20:08:17Z

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

Will Portnoy (willportnoy) · 2026-07-11T20:48:36Z

Cherry-pick of #985 (squash commit f5ad1f20) onto ulitebox.

Dynamically-linked ET_EXEC (non-PIE) binaries load at their low canonical vaddrs and grow their glibc brk heap upward from there, but the ELF interpreter was reserved at a fixed low offset directly above the main image — capping the heap, so a heap-heavy process (e.g. a bundled node) hit ENOMEM the moment it crossed that offset. This loads the interpreter at the top of the address space instead, mirroring how the kernel places ld.so for an ET_EXEC main and leaving the whole gap above the main image free for the heap; it is a no-op for PIE mains, whose interpreter already loads high.

…pped (#985) Dynamically-linked ET_EXEC (non-PIE) binaries load at their low canonical vaddrs and grow their glibc `brk` heap upward from there, but the ELF interpreter was reserved at a fixed low offset directly above the main image — capping the heap, so a heap-heavy process (e.g. a bundled `node`) hit `ENOMEM` the moment it crossed that offset. This loads the interpreter at the top of the address space instead, mirroring how the kernel places `ld.so` for an ET_EXEC main and leaving the whole gap above the main image free for the heap; it is a no-op for PIE mains, whose interpreter already loads high. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-12T20:08:17Z

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

Will Portnoy (willportnoy) · 2026-07-11T20:48:36Z

Cherry-pick of #985 (squash commit f5ad1f20) onto ulitebox.

Dynamically-linked ET_EXEC (non-PIE) binaries load at their low canonical vaddrs and grow their glibc brk heap upward from there, but the ELF interpreter was reserved at a fixed low offset directly above the main image — capping the heap, so a heap-heavy process (e.g. a bundled node) hit ENOMEM the moment it crossed that offset. This loads the interpreter at the top of the address space instead, mirroring how the kernel places ld.so for an ET_EXEC main and leaving the whole gap above the main image free for the heap; it is a no-op for PIE mains, whose interpreter already loads high.

…pped (#985) Dynamically-linked ET_EXEC (non-PIE) binaries load at their low canonical vaddrs and grow their glibc `brk` heap upward from there, but the ELF interpreter was reserved at a fixed low offset directly above the main image — capping the heap, so a heap-heavy process (e.g. a bundled `node`) hit `ENOMEM` the moment it crossed that offset. This loads the interpreter at the top of the address space instead, mirroring how the kernel places `ld.so` for an ET_EXEC main and leaving the whole gap above the main image free for the heap; it is a no-op for PIE mains, whose interpreter already loads high. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-12T20:08:17Z

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

Will Portnoy (willportnoy) · 2026-07-11T20:48:36Z

Cherry-pick of #985 (squash commit f5ad1f20) onto ulitebox.

Dynamically-linked ET_EXEC (non-PIE) binaries load at their low canonical vaddrs and grow their glibc brk heap upward from there, but the ELF interpreter was reserved at a fixed low offset directly above the main image — capping the heap, so a heap-heavy process (e.g. a bundled node) hit ENOMEM the moment it crossed that offset. This loads the interpreter at the top of the address space instead, mirroring how the kernel places ld.so for an ET_EXEC main and leaving the whole gap above the main image free for the heap; it is a no-op for PIE mains, whose interpreter already loads high.

…pped (#985) Dynamically-linked ET_EXEC (non-PIE) binaries load at their low canonical vaddrs and grow their glibc `brk` heap upward from there, but the ELF interpreter was reserved at a fixed low offset directly above the main image — capping the heap, so a heap-heavy process (e.g. a bundled `node`) hit `ENOMEM` the moment it crossed that offset. This loads the interpreter at the top of the address space instead, mirroring how the kernel places `ld.so` for an ET_EXEC main and leaving the whole gap above the main image free for the heap; it is a no-op for PIE mains, whose interpreter already loads high. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-12T20:08:17Z

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

Will Portnoy (willportnoy) · 2026-07-11T20:48:36Z

Cherry-pick of #985 (squash commit f5ad1f20) onto ulitebox.

Dynamically-linked ET_EXEC (non-PIE) binaries load at their low canonical vaddrs and grow their glibc brk heap upward from there, but the ELF interpreter was reserved at a fixed low offset directly above the main image — capping the heap, so a heap-heavy process (e.g. a bundled node) hit ENOMEM the moment it crossed that offset. This loads the interpreter at the top of the address space instead, mirroring how the kernel places ld.so for an ET_EXEC main and leaving the whole gap above the main image free for the heap; it is a no-op for PIE mains, whose interpreter already loads high.

…pped (#985) Dynamically-linked ET_EXEC (non-PIE) binaries load at their low canonical vaddrs and grow their glibc `brk` heap upward from there, but the ELF interpreter was reserved at a fixed low offset directly above the main image — capping the heap, so a heap-heavy process (e.g. a bundled `node`) hit `ENOMEM` the moment it crossed that offset. This loads the interpreter at the top of the address space instead, mirroring how the kernel places `ld.so` for an ET_EXEC main and leaving the whole gap above the main image free for the heap; it is a no-op for PIE mains, whose interpreter already loads high. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-12T20:08:17Z

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

Will Portnoy (willportnoy) · 2026-07-11T20:48:36Z

Cherry-pick of #985 (squash commit f5ad1f20) onto ulitebox.

Dynamically-linked ET_EXEC (non-PIE) binaries load at their low canonical vaddrs and grow their glibc brk heap upward from there, but the ELF interpreter was reserved at a fixed low offset directly above the main image — capping the heap, so a heap-heavy process (e.g. a bundled node) hit ENOMEM the moment it crossed that offset. This loads the interpreter at the top of the address space instead, mirroring how the kernel places ld.so for an ET_EXEC main and leaving the whole gap above the main image free for the heap; it is a no-op for PIE mains, whose interpreter already loads high.

…pped (#985) Dynamically-linked ET_EXEC (non-PIE) binaries load at their low canonical vaddrs and grow their glibc `brk` heap upward from there, but the ELF interpreter was reserved at a fixed low offset directly above the main image — capping the heap, so a heap-heavy process (e.g. a bundled `node`) hit `ENOMEM` the moment it crossed that offset. This loads the interpreter at the top of the address space instead, mirroring how the kernel places `ld.so` for an ET_EXEC main and leaving the whole gap above the main image free for the heap; it is a no-op for PIE mains, whose interpreter already loads high. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-12T20:08:17Z

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

Will Portnoy (willportnoy) · 2026-07-11T20:48:36Z

Cherry-pick of #985 (squash commit f5ad1f20) onto ulitebox.

Dynamically-linked ET_EXEC (non-PIE) binaries load at their low canonical vaddrs and grow their glibc brk heap upward from there, but the ELF interpreter was reserved at a fixed low offset directly above the main image — capping the heap, so a heap-heavy process (e.g. a bundled node) hit ENOMEM the moment it crossed that offset. This loads the interpreter at the top of the address space instead, mirroring how the kernel places ld.so for an ET_EXEC main and leaving the whole gap above the main image free for the heap; it is a no-op for PIE mains, whose interpreter already loads high.

…pped (#985) Dynamically-linked ET_EXEC (non-PIE) binaries load at their low canonical vaddrs and grow their glibc `brk` heap upward from there, but the ELF interpreter was reserved at a fixed low offset directly above the main image — capping the heap, so a heap-heavy process (e.g. a bundled `node`) hit `ENOMEM` the moment it crossed that offset. This loads the interpreter at the top of the address space instead, mirroring how the kernel places `ld.so` for an ET_EXEC main and leaving the whole gap above the main image free for the heap; it is a no-op for PIE mains, whose interpreter already loads high. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-12T20:08:17Z

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

Will Portnoy (willportnoy) added this pull request to the merge queue Jul 12, 2026

Merged via the queue into ulitebox with commit 9ce5b2eJul 12, 2026
8 checks passed