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

Will Portnoy (willportnoy) · 2026-06-30T02:18:32Z

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.

Load PT_INTERP images from the top of the Litebox task address space so ET_EXEC brk growth is not capped by ld.so at the low PIE hint. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

… load_high reserve-once - Remove `out_of_range_mmap_hint_fails_instead_of_falling_back_top_down`: it characterized `get_unmmaped_area` behavior (a different layer) that the loader fix doesn't actually depend on for correctness (the fix uses an in-range `TASK_ADDR_MAX - mapping_len` hint). The `et_exec_interpreter_loads_top_down` repro is the meaningful test and stays. - Document that the loader reserves an image's whole PT_LOAD span in a single `MapMemory::reserve` call, so `load_high` applies to exactly one reservation per image, and add a `debug_assert` (cfg(debug_assertions)-gated tracking field, so it compiles out cleanly in release) that catches a second `load_high` reservation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Removing the out_of_range mmap test orphaned its `litebox_common_linux::ProtFlags` import; the lib-only build didn't catch it but CI's `clippy --all-targets` does. The remaining et_exec test doesn't use ProtFlags (MapFlags comes via `super::*`). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Weidong Cui (wdcui) · 2026-06-30T14:58:52Z

Please shorten the PR summary to 2-3 sentences.

Per PR review, pass no mmap hint for the `load_high` (ELF interpreter) reservation instead of computing an explicit `TASK_ADDR_MAX - mapping_len` address. With no hint, `get_unmmaped_area` runs its top-down search and returns the highest free slot — exactly the placement we want, so the low ET_EXEC brk heap below stays uncapped. This drops the explicit arithmetic and the reserve-once `debug_assert` (no longer needed: each reservation independently top-down-searches the live VMA tree), and it does not depend on any platform honoring an out-of-range hint. `et_exec_interpreter_loads_top_down_above_low_heap` still passes, with the interpreter landing at `TASK_ADDR_MAX - PAGE_SIZE`. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…slot The et_exec test asserted the interpreter lands at the exact `TASK_ADDR_MAX - PAGE_SIZE` slot, which the no-hint reservation only hits when the very top is clear. With no hint, `get_unmmaped_area` returns the highest free gap, and host mappings seeded into the userland VMA tree (see `mm/linux.rs`) can sit near the top and push that gap below the top slot — CI observed `0x7fc1…` (still ~140 TB, heap uncapped) rather than the exact top, failing the strict assertion though the fix's invariant held. Relax the assertion to what actually matters: the interpreter is placed in the high half of the address space, far above the low-heap region, so the low ET_EXEC brk heap is not capped. Robust across platforms and ASLR since it no longer pins one exact address. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-01T14:31:03Z

🤖 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.

Weiteng Chen (CvvT)

LGTM, thanks!

Weidong Cui (wdcui) · 2026-07-11T05:15:53Z

Will Portnoy (@willportnoy), please feel free to merge your PR, and cherry pick it over to ulitebox. I hope you were not waiting for my approval. Thanks!

Will Portnoy (willportnoy) · 2026-06-30T02:18:32Z

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.

Load PT_INTERP images from the top of the Litebox task address space so ET_EXEC brk growth is not capped by ld.so at the low PIE hint. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

… load_high reserve-once - Remove `out_of_range_mmap_hint_fails_instead_of_falling_back_top_down`: it characterized `get_unmmaped_area` behavior (a different layer) that the loader fix doesn't actually depend on for correctness (the fix uses an in-range `TASK_ADDR_MAX - mapping_len` hint). The `et_exec_interpreter_loads_top_down` repro is the meaningful test and stays. - Document that the loader reserves an image's whole PT_LOAD span in a single `MapMemory::reserve` call, so `load_high` applies to exactly one reservation per image, and add a `debug_assert` (cfg(debug_assertions)-gated tracking field, so it compiles out cleanly in release) that catches a second `load_high` reservation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Removing the out_of_range mmap test orphaned its `litebox_common_linux::ProtFlags` import; the lib-only build didn't catch it but CI's `clippy --all-targets` does. The remaining et_exec test doesn't use ProtFlags (MapFlags comes via `super::*`). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Weidong Cui (wdcui) · 2026-06-30T14:58:52Z

Please shorten the PR summary to 2-3 sentences.

Per PR review, pass no mmap hint for the `load_high` (ELF interpreter) reservation instead of computing an explicit `TASK_ADDR_MAX - mapping_len` address. With no hint, `get_unmmaped_area` runs its top-down search and returns the highest free slot — exactly the placement we want, so the low ET_EXEC brk heap below stays uncapped. This drops the explicit arithmetic and the reserve-once `debug_assert` (no longer needed: each reservation independently top-down-searches the live VMA tree), and it does not depend on any platform honoring an out-of-range hint. `et_exec_interpreter_loads_top_down_above_low_heap` still passes, with the interpreter landing at `TASK_ADDR_MAX - PAGE_SIZE`. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…slot The et_exec test asserted the interpreter lands at the exact `TASK_ADDR_MAX - PAGE_SIZE` slot, which the no-hint reservation only hits when the very top is clear. With no hint, `get_unmmaped_area` returns the highest free gap, and host mappings seeded into the userland VMA tree (see `mm/linux.rs`) can sit near the top and push that gap below the top slot — CI observed `0x7fc1…` (still ~140 TB, heap uncapped) rather than the exact top, failing the strict assertion though the fix's invariant held. Relax the assertion to what actually matters: the interpreter is placed in the high half of the address space, far above the low-heap region, so the low ET_EXEC brk heap is not capped. Robust across platforms and ASLR since it no longer pins one exact address. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-01T14:31:03Z

🤖 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.

Weiteng Chen (CvvT)

LGTM, thanks!

Weidong Cui (wdcui) · 2026-07-11T05:15:53Z

Will Portnoy (@willportnoy), please feel free to merge your PR, and cherry pick it over to ulitebox. I hope you were not waiting for my approval. Thanks!

Will Portnoy (willportnoy) · 2026-06-30T02:18:32Z

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.

Load PT_INTERP images from the top of the Litebox task address space so ET_EXEC brk growth is not capped by ld.so at the low PIE hint. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

… load_high reserve-once - Remove `out_of_range_mmap_hint_fails_instead_of_falling_back_top_down`: it characterized `get_unmmaped_area` behavior (a different layer) that the loader fix doesn't actually depend on for correctness (the fix uses an in-range `TASK_ADDR_MAX - mapping_len` hint). The `et_exec_interpreter_loads_top_down` repro is the meaningful test and stays. - Document that the loader reserves an image's whole PT_LOAD span in a single `MapMemory::reserve` call, so `load_high` applies to exactly one reservation per image, and add a `debug_assert` (cfg(debug_assertions)-gated tracking field, so it compiles out cleanly in release) that catches a second `load_high` reservation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Removing the out_of_range mmap test orphaned its `litebox_common_linux::ProtFlags` import; the lib-only build didn't catch it but CI's `clippy --all-targets` does. The remaining et_exec test doesn't use ProtFlags (MapFlags comes via `super::*`). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Weidong Cui (wdcui) · 2026-06-30T14:58:52Z

Please shorten the PR summary to 2-3 sentences.

Per PR review, pass no mmap hint for the `load_high` (ELF interpreter) reservation instead of computing an explicit `TASK_ADDR_MAX - mapping_len` address. With no hint, `get_unmmaped_area` runs its top-down search and returns the highest free slot — exactly the placement we want, so the low ET_EXEC brk heap below stays uncapped. This drops the explicit arithmetic and the reserve-once `debug_assert` (no longer needed: each reservation independently top-down-searches the live VMA tree), and it does not depend on any platform honoring an out-of-range hint. `et_exec_interpreter_loads_top_down_above_low_heap` still passes, with the interpreter landing at `TASK_ADDR_MAX - PAGE_SIZE`. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…slot The et_exec test asserted the interpreter lands at the exact `TASK_ADDR_MAX - PAGE_SIZE` slot, which the no-hint reservation only hits when the very top is clear. With no hint, `get_unmmaped_area` returns the highest free gap, and host mappings seeded into the userland VMA tree (see `mm/linux.rs`) can sit near the top and push that gap below the top slot — CI observed `0x7fc1…` (still ~140 TB, heap uncapped) rather than the exact top, failing the strict assertion though the fix's invariant held. Relax the assertion to what actually matters: the interpreter is placed in the high half of the address space, far above the low-heap region, so the low ET_EXEC brk heap is not capped. Robust across platforms and ASLR since it no longer pins one exact address. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-01T14:31:03Z

🤖 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.

Weiteng Chen (CvvT)

LGTM, thanks!

Weidong Cui (wdcui) · 2026-07-11T05:15:53Z

Will Portnoy (@willportnoy), please feel free to merge your PR, and cherry pick it over to ulitebox. I hope you were not waiting for my approval. Thanks!

Will Portnoy (willportnoy) · 2026-06-30T02:18:32Z

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.

Load PT_INTERP images from the top of the Litebox task address space so ET_EXEC brk growth is not capped by ld.so at the low PIE hint. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

… load_high reserve-once - Remove `out_of_range_mmap_hint_fails_instead_of_falling_back_top_down`: it characterized `get_unmmaped_area` behavior (a different layer) that the loader fix doesn't actually depend on for correctness (the fix uses an in-range `TASK_ADDR_MAX - mapping_len` hint). The `et_exec_interpreter_loads_top_down` repro is the meaningful test and stays. - Document that the loader reserves an image's whole PT_LOAD span in a single `MapMemory::reserve` call, so `load_high` applies to exactly one reservation per image, and add a `debug_assert` (cfg(debug_assertions)-gated tracking field, so it compiles out cleanly in release) that catches a second `load_high` reservation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Removing the out_of_range mmap test orphaned its `litebox_common_linux::ProtFlags` import; the lib-only build didn't catch it but CI's `clippy --all-targets` does. The remaining et_exec test doesn't use ProtFlags (MapFlags comes via `super::*`). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Weidong Cui (wdcui) · 2026-06-30T14:58:52Z

Please shorten the PR summary to 2-3 sentences.

Per PR review, pass no mmap hint for the `load_high` (ELF interpreter) reservation instead of computing an explicit `TASK_ADDR_MAX - mapping_len` address. With no hint, `get_unmmaped_area` runs its top-down search and returns the highest free slot — exactly the placement we want, so the low ET_EXEC brk heap below stays uncapped. This drops the explicit arithmetic and the reserve-once `debug_assert` (no longer needed: each reservation independently top-down-searches the live VMA tree), and it does not depend on any platform honoring an out-of-range hint. `et_exec_interpreter_loads_top_down_above_low_heap` still passes, with the interpreter landing at `TASK_ADDR_MAX - PAGE_SIZE`. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…slot The et_exec test asserted the interpreter lands at the exact `TASK_ADDR_MAX - PAGE_SIZE` slot, which the no-hint reservation only hits when the very top is clear. With no hint, `get_unmmaped_area` returns the highest free gap, and host mappings seeded into the userland VMA tree (see `mm/linux.rs`) can sit near the top and push that gap below the top slot — CI observed `0x7fc1…` (still ~140 TB, heap uncapped) rather than the exact top, failing the strict assertion though the fix's invariant held. Relax the assertion to what actually matters: the interpreter is placed in the high half of the address space, far above the low-heap region, so the low ET_EXEC brk heap is not capped. Robust across platforms and ASLR since it no longer pins one exact address. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-01T14:31:03Z

🤖 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.

Weiteng Chen (CvvT)

LGTM, thanks!

Weidong Cui (wdcui) · 2026-07-11T05:15:53Z

Will Portnoy (@willportnoy), please feel free to merge your PR, and cherry pick it over to ulitebox. I hope you were not waiting for my approval. Thanks!

Will Portnoy (willportnoy) · 2026-06-30T02:18:32Z

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.

Load PT_INTERP images from the top of the Litebox task address space so ET_EXEC brk growth is not capped by ld.so at the low PIE hint. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

… load_high reserve-once - Remove `out_of_range_mmap_hint_fails_instead_of_falling_back_top_down`: it characterized `get_unmmaped_area` behavior (a different layer) that the loader fix doesn't actually depend on for correctness (the fix uses an in-range `TASK_ADDR_MAX - mapping_len` hint). The `et_exec_interpreter_loads_top_down` repro is the meaningful test and stays. - Document that the loader reserves an image's whole PT_LOAD span in a single `MapMemory::reserve` call, so `load_high` applies to exactly one reservation per image, and add a `debug_assert` (cfg(debug_assertions)-gated tracking field, so it compiles out cleanly in release) that catches a second `load_high` reservation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Removing the out_of_range mmap test orphaned its `litebox_common_linux::ProtFlags` import; the lib-only build didn't catch it but CI's `clippy --all-targets` does. The remaining et_exec test doesn't use ProtFlags (MapFlags comes via `super::*`). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Weidong Cui (wdcui) · 2026-06-30T14:58:52Z

Please shorten the PR summary to 2-3 sentences.

Per PR review, pass no mmap hint for the `load_high` (ELF interpreter) reservation instead of computing an explicit `TASK_ADDR_MAX - mapping_len` address. With no hint, `get_unmmaped_area` runs its top-down search and returns the highest free slot — exactly the placement we want, so the low ET_EXEC brk heap below stays uncapped. This drops the explicit arithmetic and the reserve-once `debug_assert` (no longer needed: each reservation independently top-down-searches the live VMA tree), and it does not depend on any platform honoring an out-of-range hint. `et_exec_interpreter_loads_top_down_above_low_heap` still passes, with the interpreter landing at `TASK_ADDR_MAX - PAGE_SIZE`. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…slot The et_exec test asserted the interpreter lands at the exact `TASK_ADDR_MAX - PAGE_SIZE` slot, which the no-hint reservation only hits when the very top is clear. With no hint, `get_unmmaped_area` returns the highest free gap, and host mappings seeded into the userland VMA tree (see `mm/linux.rs`) can sit near the top and push that gap below the top slot — CI observed `0x7fc1…` (still ~140 TB, heap uncapped) rather than the exact top, failing the strict assertion though the fix's invariant held. Relax the assertion to what actually matters: the interpreter is placed in the high half of the address space, far above the low-heap region, so the low ET_EXEC brk heap is not capped. Robust across platforms and ASLR since it no longer pins one exact address. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-01T14:31:03Z

🤖 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.

Weiteng Chen (CvvT)

LGTM, thanks!

Weidong Cui (wdcui) · 2026-07-11T05:15:53Z

Will Portnoy (@willportnoy), please feel free to merge your PR, and cherry pick it over to ulitebox. I hope you were not waiting for my approval. Thanks!

Will Portnoy (willportnoy) · 2026-06-30T02:18:32Z

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.

Load PT_INTERP images from the top of the Litebox task address space so ET_EXEC brk growth is not capped by ld.so at the low PIE hint. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

… load_high reserve-once - Remove `out_of_range_mmap_hint_fails_instead_of_falling_back_top_down`: it characterized `get_unmmaped_area` behavior (a different layer) that the loader fix doesn't actually depend on for correctness (the fix uses an in-range `TASK_ADDR_MAX - mapping_len` hint). The `et_exec_interpreter_loads_top_down` repro is the meaningful test and stays. - Document that the loader reserves an image's whole PT_LOAD span in a single `MapMemory::reserve` call, so `load_high` applies to exactly one reservation per image, and add a `debug_assert` (cfg(debug_assertions)-gated tracking field, so it compiles out cleanly in release) that catches a second `load_high` reservation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Removing the out_of_range mmap test orphaned its `litebox_common_linux::ProtFlags` import; the lib-only build didn't catch it but CI's `clippy --all-targets` does. The remaining et_exec test doesn't use ProtFlags (MapFlags comes via `super::*`). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Weidong Cui (wdcui) · 2026-06-30T14:58:52Z

Please shorten the PR summary to 2-3 sentences.

Per PR review, pass no mmap hint for the `load_high` (ELF interpreter) reservation instead of computing an explicit `TASK_ADDR_MAX - mapping_len` address. With no hint, `get_unmmaped_area` runs its top-down search and returns the highest free slot — exactly the placement we want, so the low ET_EXEC brk heap below stays uncapped. This drops the explicit arithmetic and the reserve-once `debug_assert` (no longer needed: each reservation independently top-down-searches the live VMA tree), and it does not depend on any platform honoring an out-of-range hint. `et_exec_interpreter_loads_top_down_above_low_heap` still passes, with the interpreter landing at `TASK_ADDR_MAX - PAGE_SIZE`. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…slot The et_exec test asserted the interpreter lands at the exact `TASK_ADDR_MAX - PAGE_SIZE` slot, which the no-hint reservation only hits when the very top is clear. With no hint, `get_unmmaped_area` returns the highest free gap, and host mappings seeded into the userland VMA tree (see `mm/linux.rs`) can sit near the top and push that gap below the top slot — CI observed `0x7fc1…` (still ~140 TB, heap uncapped) rather than the exact top, failing the strict assertion though the fix's invariant held. Relax the assertion to what actually matters: the interpreter is placed in the high half of the address space, far above the low-heap region, so the low ET_EXEC brk heap is not capped. Robust across platforms and ASLR since it no longer pins one exact address. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-01T14:31:03Z

🤖 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.

Weiteng Chen (CvvT)

LGTM, thanks!

Weidong Cui (wdcui) · 2026-07-11T05:15:53Z

Will Portnoy (@willportnoy), please feel free to merge your PR, and cherry pick it over to ulitebox. I hope you were not waiting for my approval. Thanks!

Will Portnoy (willportnoy) · 2026-06-30T02:18:32Z

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.

Load PT_INTERP images from the top of the Litebox task address space so ET_EXEC brk growth is not capped by ld.so at the low PIE hint. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

… load_high reserve-once - Remove `out_of_range_mmap_hint_fails_instead_of_falling_back_top_down`: it characterized `get_unmmaped_area` behavior (a different layer) that the loader fix doesn't actually depend on for correctness (the fix uses an in-range `TASK_ADDR_MAX - mapping_len` hint). The `et_exec_interpreter_loads_top_down` repro is the meaningful test and stays. - Document that the loader reserves an image's whole PT_LOAD span in a single `MapMemory::reserve` call, so `load_high` applies to exactly one reservation per image, and add a `debug_assert` (cfg(debug_assertions)-gated tracking field, so it compiles out cleanly in release) that catches a second `load_high` reservation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Removing the out_of_range mmap test orphaned its `litebox_common_linux::ProtFlags` import; the lib-only build didn't catch it but CI's `clippy --all-targets` does. The remaining et_exec test doesn't use ProtFlags (MapFlags comes via `super::*`). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Weidong Cui (wdcui) · 2026-06-30T14:58:52Z

Please shorten the PR summary to 2-3 sentences.

Per PR review, pass no mmap hint for the `load_high` (ELF interpreter) reservation instead of computing an explicit `TASK_ADDR_MAX - mapping_len` address. With no hint, `get_unmmaped_area` runs its top-down search and returns the highest free slot — exactly the placement we want, so the low ET_EXEC brk heap below stays uncapped. This drops the explicit arithmetic and the reserve-once `debug_assert` (no longer needed: each reservation independently top-down-searches the live VMA tree), and it does not depend on any platform honoring an out-of-range hint. `et_exec_interpreter_loads_top_down_above_low_heap` still passes, with the interpreter landing at `TASK_ADDR_MAX - PAGE_SIZE`. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…slot The et_exec test asserted the interpreter lands at the exact `TASK_ADDR_MAX - PAGE_SIZE` slot, which the no-hint reservation only hits when the very top is clear. With no hint, `get_unmmaped_area` returns the highest free gap, and host mappings seeded into the userland VMA tree (see `mm/linux.rs`) can sit near the top and push that gap below the top slot — CI observed `0x7fc1…` (still ~140 TB, heap uncapped) rather than the exact top, failing the strict assertion though the fix's invariant held. Relax the assertion to what actually matters: the interpreter is placed in the high half of the address space, far above the low-heap region, so the low ET_EXEC brk heap is not capped. Robust across platforms and ASLR since it no longer pins one exact address. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-01T14:31:03Z

🤖 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.

Weiteng Chen (CvvT)

LGTM, thanks!

Weidong Cui (wdcui) · 2026-07-11T05:15:53Z

Will Portnoy (@willportnoy), please feel free to merge your PR, and cherry pick it over to ulitebox. I hope you were not waiting for my approval. Thanks!

Will Portnoy (willportnoy) · 2026-06-30T02:18:32Z

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.

Load PT_INTERP images from the top of the Litebox task address space so ET_EXEC brk growth is not capped by ld.so at the low PIE hint. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

… load_high reserve-once - Remove `out_of_range_mmap_hint_fails_instead_of_falling_back_top_down`: it characterized `get_unmmaped_area` behavior (a different layer) that the loader fix doesn't actually depend on for correctness (the fix uses an in-range `TASK_ADDR_MAX - mapping_len` hint). The `et_exec_interpreter_loads_top_down` repro is the meaningful test and stays. - Document that the loader reserves an image's whole PT_LOAD span in a single `MapMemory::reserve` call, so `load_high` applies to exactly one reservation per image, and add a `debug_assert` (cfg(debug_assertions)-gated tracking field, so it compiles out cleanly in release) that catches a second `load_high` reservation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Removing the out_of_range mmap test orphaned its `litebox_common_linux::ProtFlags` import; the lib-only build didn't catch it but CI's `clippy --all-targets` does. The remaining et_exec test doesn't use ProtFlags (MapFlags comes via `super::*`). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Weidong Cui (wdcui) · 2026-06-30T14:58:52Z

Please shorten the PR summary to 2-3 sentences.

Per PR review, pass no mmap hint for the `load_high` (ELF interpreter) reservation instead of computing an explicit `TASK_ADDR_MAX - mapping_len` address. With no hint, `get_unmmaped_area` runs its top-down search and returns the highest free slot — exactly the placement we want, so the low ET_EXEC brk heap below stays uncapped. This drops the explicit arithmetic and the reserve-once `debug_assert` (no longer needed: each reservation independently top-down-searches the live VMA tree), and it does not depend on any platform honoring an out-of-range hint. `et_exec_interpreter_loads_top_down_above_low_heap` still passes, with the interpreter landing at `TASK_ADDR_MAX - PAGE_SIZE`. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…slot The et_exec test asserted the interpreter lands at the exact `TASK_ADDR_MAX - PAGE_SIZE` slot, which the no-hint reservation only hits when the very top is clear. With no hint, `get_unmmaped_area` returns the highest free gap, and host mappings seeded into the userland VMA tree (see `mm/linux.rs`) can sit near the top and push that gap below the top slot — CI observed `0x7fc1…` (still ~140 TB, heap uncapped) rather than the exact top, failing the strict assertion though the fix's invariant held. Relax the assertion to what actually matters: the interpreter is placed in the high half of the address space, far above the low-heap region, so the low ET_EXEC brk heap is not capped. Robust across platforms and ASLR since it no longer pins one exact address. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-01T14:31:03Z

🤖 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.

Weiteng Chen (CvvT)

LGTM, thanks!

Weidong Cui (wdcui) · 2026-07-11T05:15:53Z

Will Portnoy (@willportnoy), please feel free to merge your PR, and cherry pick it over to ulitebox. I hope you were not waiting for my approval. Thanks!

fix: load ELF interpreters high
be617ed
Load PT_INTERP images from the top of the Litebox task address space so ET_EXEC brk growth is not capped by ld.so at the low PIE hint. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Weidong Cui (wdcui) reviewed Jun 30, 2026
View reviewed changes

Comment threadlitebox_shim_linux/src/loader/elf.rs Outdated

Weidong Cui (wdcui) reviewed Jun 30, 2026
View reviewed changes

Comment threadlitebox_shim_linux/src/loader/elf.rs

Will Portnoy (willportnoy)and others added 2 commits June 30, 2026 14:21

Weiteng Chen (CvvT) reviewed Jul 1, 2026
View reviewed changes

Comment threadlitebox_shim_linux/src/loader/elf.rs Outdated

Will Portnoy (willportnoy)and others added 2 commits July 1, 2026 14:02

Weiteng Chen (CvvT) approved these changes Jul 1, 2026
View reviewed changes

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

Merged via the queue into main with commit f5ad1f2Jul 11, 2026
14 checks passed

Will Portnoy (willportnoy) deleted the wportnoy/heap-headroom branch July 11, 2026 20:42

Will Portnoy (willportnoy) mentioned this pull request Jul 11, 2026
Load ELF interpreter high so a low-loaded ET_EXEC's brk heap isn't capped #1023
Merged