On Tue, May 14, 2024 at 05:47:30PM -0600, Theo de Raadt wrote: > Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > I worry that the non-atomicity will one day be used by an attacker. > > > > How might an attacker exploit this? > > Various ways which are going to be very application specific. Most ways > will depend on munmap / mprotect arguments being incorrect for some > reason, and callers not checking the return values. > > After the system call, the memory is in a very surprising configuration. > > Consider a larger memory region containing the following sections: > > [regular memory] [sealed memory] [regular memory containing a secret] > > unmap() gets called on the whole region, for some reason. The first > section is removed. It hits the sealed memory, and returns EPERM. It does > not unmap the sealed reason, not the memory containing the secret. If we consider that the attack consists, for an attacker, in mseal()ing the beginning of an area to make sure to pin the whole area by making a future munmap() fail, maybe we could make munmap() not stop anymore on such errors and continue to unmap the rest of the area, for the purpose of not leaving such a theoretical attack vector work ? After all, munmap() currently skips wholes and continues to unmap the area. But then what would prevent the attacker from doing mseal() on the whole area in this case, to prevent it from being unmapped ? Wouldn't it be more effective to have a non-resettable prctl() allowing the application to prefer to be killed upon such an munmap() failure in order to stay consistent and more robust against such class of attacks? Willy
