issues: a program run from /tmp pages in rewritable code, and a process's mapping count is bounded only by its window

issues/isolation/a-program-run-from-tmp-pages-in-code-any-process-can-rewrite.md

@@ -0,0 +1,26 @@
+---
+status: open
+kind: defect
+opened: 2026-10-03
+---
+
+# A program run from `/tmp` pages in code any process can rewrite
+
+A spawn by path of a `/tmp` file maps each `PT_LOAD` segment as a file-backed
+region over a `TmpfsBacking` (`insert_elf_regions`, `kernel/src/loader/mod.rs`),
+and a fault fills its 2 MiB window from the file cache as the file is at that
+fault (`handle_page_fault`, `kernel/src/process.rs`; `TmpfsBacking::read_page`,
+`kernel/src/tmpfs.rs`). Nothing copies the file at the spawn and nothing refuses
+a write to it while a process pages from it, so a write after the spawn reaches
+every window of the running program not yet faulted in, its code included.
+`/tmp` is writable by every process, so the writer need not be the spawner: one
+program changes another's code. `SharedImage` (`kernel/src/file_backing.rs`) has
+the same shape on the image route and is bounded there by who can write: the
+object is the spawner's own. `issues/isolation/a-swapped-binary-lives-where-any-process-can-rewrite-it.md`
+is this defect for the swap's installed binaries.
+
+By reading, unmeasured.
+
+Owner: orchestrator. Exit condition: a test spawns a `/tmp` executable, rewrites
+a window of its code the child has not yet run, then has the child run it, and
+reds while the child runs the rewritten bytes.

issues/kernel/a-processs-mapping-count-is-bounded-only-by-its-address-window.md

@@ -0,0 +1,30 @@
+---
+status: open
+kind: defect
+opened: 2026-10-03
+---
+
+# A process's mapping count is bounded only by its address window
+
+Every `mmap` adds a `Region` to the address space's map and an `MmapRegion` to
+`ProcessData::mmap_regions` (`sys_mmap`, `kernel/src/syscall/vm.rs`), and
+nothing bounds how many one process holds but the placement window
+(`kernel/src/vma.rs`): 8 GiB to `STACK_BASE` in 2 MiB pages, 260,094
+placements with the 2 MiB guard and 520,188 `FIXED` ones without it. A
+`PROT_NONE` mapping pins no physical page, so a loop of them costs the process
+nothing and the kernel heap one record in each ledger.
+
+`mmap_regions` is a `Vec` of 40-byte records (`UserAddr`, `usize`,
+`Option<PageAlloc>`). The push past 32,768 records grows it to 65,536, an
+allocation of 2,621,440 bytes, past `mm::MAX_HEAP_ALLOC` (2,093,056), where
+`KernelAllocator::alloc` (`kernel/src/mm/alloc.rs`) asserts: a kernel panic from
+one unprivileged process. Below that point the records of many such processes
+are kernel heap charged to nobody, and a heap that cannot grow answers `alloc`
+with a null, which panics too.
+
+By reading, unmeasured: the 40 bytes are read off the struct, and the counts
+are that arithmetic over `vma.rs`'s constants.
+
+Owner: orchestrator. Exit condition: `mmap` refuses by name the mapping past a
+per-process bound, and a test that maps `PROT_NONE` until refused reads that
+refusal and a live kernel; it reds today on the panic.