On Fri, Jun 28, 2024 at 3:33 PM Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote: > > > Yep, makes sense. I'm currently reworking this whole lib/buildid.c > > implementation to remove all the restrictions on data being in the > > first page only, and making it work in a faultable context more > > reliably. I can audit the code for TOCTOU issues and incorporate your > > feedback. I'll probably post the patch set next week, will cc you as > > well. > > Please also add checks that the mapping is executable, to > close the obscure "can check the first 4 bytes of every mapped > file is ELF\0" hole. > > But it will still need the hardening because mappings from > ld.so are not EBUSY for writes. I'm a bit confused. Two things: 1) non-executable file-backed VMA still has build ID associated with it. Note, build ID is extracted from the backing file's content, not from VMA itself. The part of ELF file that contains build ID isn't necessarily mmap()'ed at all 2) What sort of exploitation are we talking about here? it's not enough for backing file to have correct 4 starting bytes (0x7f"ELF"), we still have to find correct PT_NOTE segment, and .note.gnu.build-id section within it, that has correct type (3) and key name "GNU". I'm trying to understand what we are protecting against here. Especially that opening /proc/<pid>/maps already requires PTRACE_MODE_READ permissions anyways (or pid should be self). > > -Andi
