physmap-fault — Logiciel
Message écrit par le noyau (osfmk/arm64/sleh.c) quand le processeur signale, en mode noyau, un défaut d'accès (page non mappée, indicateur d'accès ou permission) sur une adresse de l'« aperture physique » (physmap), la zone qui projette toute la mémoire vive. Le noyau n'attend jamais de défaut à cet endroit : un morceau de code du noyau a lu ou écrit une page qui n'était pas (ou plus) mappée, par un pointeur périmé ou corrompu. C'est donc d'abord une classe de bug logiciel du noyau, pas un pilote en particulier ; une corruption de mémoire matérielle (bit inversé dans un pointeur) est possible mais rare et ne se reproduit pas à l'identique. Sur deux logs d'iPhone 16 (iOS 18.6.2) analysés : même instruction fautive malgré des adresses différentes (KASLR), même processus (mediaplaybackd), même chemin via apfs, copie depuis une page physmap non mappée (ESR 0x96000007 = erreur de traduction niveau 3) : panique reproductible sur un chemin de code précis, ce qui oriente vers un bug d'iOS plutôt que vers la mémoire ou le SoC.
iPhone
Logiciel d'abord (bug du noyau iOS / système de fichiers) ; mémoire ou carte mère seulement si ça persiste sur iOS propre
Première vérification
Mettre à jour iOS ; si la panique revient, restaurer par ordinateur en appareil neuf sans sauvegarde, et noter le processus en cause (« panicked task ») : s'il est toujours le même (ex.
Sources
- Apple XNU – sleh.c, handle_kernel_abort(): “Ensure no faults in the physical aperture…” → panic_with_thread_kernel_state("Unexpected fault in kernel physical aperture") ↗
- Apple XNU – proc_reg.h (fault status codes: FSC_TRANSLATION_FAULT_L3 = 0x07) ↗
- Apple Developer Forums #124127 – iOS system panic “Kernel data abort”: DTS engineer's reply (kernel panic = system-side bug, to be reported with a sysdiagnose) ↗
- iFixit – iPhone Kernel Panics (wiki): kernel panic, “software first” when nothing points to a component ↗