MTE false-positive with shared userspace/kernel mapping

[Andrey Konovalov]

Hi Catalin,

Syzbot reported an issue originating from the packet sockets code [1],
but it seems to be an MTE false-positive with a shared
userspace/kernel mapping.

The problem is that mmap_region calls arch_validate_flags to check
VM_MTE_ALLOWED only after mapping memory for a non-anonymous mapping
via call_mmap().

What happens in the reproducer [2] is:

1. Userspace creates a packet socket and makes the kernel allocate the
backing memory for a shared mapping via alloc_one_pg_vec_page.
2. Userspace calls mmap _with PROT_MTE_ on a packet socket file descriptor.
3. mmap code sets VM_MTE via calc_vm_prot_bits(), as PROT_MTE has been provided.
3. mmap code calls the packet socket mmap handler packet_mmap via
call_mmap() (without checking VM_MTE_ALLOWED at this point).
4. Packet socket code uses vm_insert_page to map the memory allocated
in step #1 to the userspace area.
5. arm64 code resets memory tags for the backing memory via
vm_insert_page->...->__set_pte_at->mte_sync_tags(), as the memory is
MT_NORMAL_TAGGED due to VM_MTE.
6. Only now the mmap code checks VM_MTE_ALLOWED via
arch_validate_flags() and unmaps the area, but the memory tags have
already been reset.
5. The packet socket code accesses the area through its tagged kernel
address via __packet_get_status(), which leads to a tag mismatch.

I'm not sure what would be the best fix here. Moving
arch_validate_flags() before call_mmap() would be an option, but maybe
you have a better suggestion.

On a side note, I think the packet sockets code ought to use GFP_USER
and vmalloc_user for allocating the backing memory in
alloc_one_pg_vec_page, but that shouldn't make any difference to MTE.

Thanks!

[1] https://syzkaller.appspot.com/bug?extid=64b0f633159fde08e1f1
[2] https://syzkaller.appspot.com/text?tag=ReproC&x=17fd0aee280000