I’m guessing the vm_shared_region_slide_page_v5 change is one of the kernel memory corruption CVEs (CVE-2026-39868 or CVE-2026-43724, can’t tell) I don’t see how the vm_map_msync issues can cause kernel memory corruption, so it’s probably not the cvevm_shared_region_map_file: an LLM thinks it might lead to read out of bounds and a denial-of-service, but no memory corruption (https://gist.github.com/zhuowei/5a78638228263e02697e43d24c8f63b7); I don’t have enough experience to tell if that’s truevm_shared_region_slide_page_v5: seems like you could get some memory corruption - if you manage to map a shared region with a page_starts that points past a page, and have your corruption target on the very next page of physical memory. Can you do that?