A page lent between processes can be declared free when its owner exits even though the borrower still maps it. The allocator can hand the same page to someone else, while the borrower retains a window into the new owner's memory.
Preconditions The lender has at least two runnable threads: one blocked in a memory lend and another able to invoke TerminateProcess. A different-PID server has received or delays the loan. The allocator later reuses the released physical page.
Impact Lending marks the lender PTE shared and maps the same physical page into the borrower without changing physical ownership. During termination, the kernel enumerates owned physical pages but passes the physical address to page_is_lent(), whose implementation expects a virtual address in the active process. A false result clears physical ownership, while the borrower's PTE and WaitingReturnMemory state survive. The allocator then zeroes and reallocates the page. Zeroing prevents recovery of the lender's old data, but the stale borrower alias remains and can observe or modify the new owner's post-reuse data.
Activity
2
xobs1mo agoI don't remember the exact details of how loaned pages work, but I believe when a process dies we mark the page as being lent-but-terminated. E.g. the entry gets turned from MemoryMessageROLend into MemoryMessageROLendTerminated. That way, when the memory is returned, we know to just discard it.
It may be that all that needs to happen is a terminated process gets a tombstone until all memory is returned, at which point the tombstone can be returned.
Alternately, maybe we can change the RPT so that all loaned pages become owned by PID 1, so they get discarded when the return happens.
This is from lisdexico's report baochip-dc34-kernel-ipc-security.
The issue is marked here for future consideration. As-is, the potential impact of this is likely small, as exploiting it requires killing a process and restarting a new one in its place - a facility that does not exist in the current system (processes that die just die, there is no spawn/respawn facility).
It is also a difficult problem to fix. The suggested remediation path is so track loans by physical page, but this would require adding potentially unbounded state tracking to each process, a thing I think we don't want to do. My intuition is a better path is to look for a time-expensive but memory-cheap solution. For example, when a process dies, the kernel may have to brute-force search through memory or process structures for orphaned items. This means terminations take a bit longer, but then we don't have to introduce bookkeeping state.
The status of this bug is indefinitely postponed. The trigger for motivating a resolution is if the ecosystem start supporting spawnable applications, especially if coming from third parties or less trusted sources. But as it is, the security model is that you have a walled garden in your device, nothing goes in or out, and attack surfaces are kept to a minimum. The exploit path would then need to look like an arbitrary code exec vulnerability, followed by the ability to crash a process, then respawn it, and then force a page to be observable through this mechanism somehow. Not mathematically impossible but probably annoying and likely to not go unnoticed by a user.