← Feed
@zhuowei@notnow.dev
2026-07-03 06:34 UTC
Diffing macOS 26.5.1 against 26.5.2:
There’s several diffs in the virtual memory subsystem - that sure sounds like the two kernel memory corruption CVEs. Now, can someone let me know which CVE matches which?
vm_map_remap: “downgrade JIT for entry” https://github.com/blacktop/ipsw-diffs/blob/20358f9cb214e9bca69d4b6c6bc5961c56c31666/26_5_1_23F81_vs_26_5_2_23F84/KEXTS/com.apple.kernel.md?plain=1#L76vm_map_copyout_internal: also has “downgrade JIT for entry”vm_map_msync: there’s now a few new checks for entry->needs_copy:
https://github.com/apple-oss-distributions/xnu/blame/ac9718fb1af618d5ce8678d0dc6e8a58f252216f/osfmk/vm/vm_map.c#L19084
now checks if (entry->needs_copy || vm_object_no_shadowing)
https://github.com/apple-oss-distributions/xnu/blob/ac9718fb1af618d5ce8678d0dc6e8a58f252216f/osfmk/vm/vm_map.c#L19114
((sync_flags & VM_SYNC_ASYNCHRONOUS|VM_SYNC_SYNCHRONOUS|VM_SYNC_INVALIDATE) && ) == VM_SYNC_INVALIDATE && entry->needs_copy)vm_shared_region_map_file: https://github.com/apple-oss-distributions/xnu/blob/ac9718fb1af618d5ce8678d0dc6e8a58f252216f/osfmk/vm/vm_shared_region.c#L2071
vm_shared_region_undo_mappings’s last argument, instead of sr_file_mappings_count, it passes sr_file_mappings[sr_file_mappings_count - 1]->mappings_countmach_make_memory_entry_share: not sure what’s changed here? there’s a new vm_mem_entry_wimg_non_writable counter at any rate.vm_shared_region_undo_mappings: now has a if (sr_map->pmap) { pmap_remove(sr_map->pmap, start, end)}memory_entry_purgeable_control_internal: https://github.com/apple-oss-distributions/xnu/blob/ac9718fb1af618d5ce8678d0dc6e8a58f252216f/osfmk/vm/vm_memory_entry.c#L1533
there’s now an extra check herevm_shared_region_slide_page_v5: https://github.com/apple-oss-distributions/xnu/blob/ac9718fb1af618d5ce8678d0dc6e8a58f252216f/osfmk/vm/vm_shared_region.c#L3510
there’s now a check for overflow here.vm_shared_region_slide_sanity_check_v3, vm_shared_region_slide_sanity_check_v5: added checks: “vm_shared_region_slide_sanity_check_v3: page_starts[%u] exceeds valid range” and “vm_shared_region_slide_sanity_check_v5: page_starts[%u] exceeds valid range”.
Replies (1)
-
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?
Open ##3555560