Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] The newly introduced global function pointer `arm64_pre_smp_shutdown_hook` is placed in writable memory without the `__ro_after_init` annotation, creating a potential target for control-flow hijacking. --
--- Patch [1]: [RFC PATCH 1/2] arm64: Add pre-shutdown hook to machine_shutdown() --- commit 438763f14354dbd91b5fa7bea807c334ada0c642 Author: Shradha Gupta <[email protected]> arm64: Add pre-shutdown hook to machine_shutdown() This patch introduces a global function pointer invoked from machine_shutdown() to allow platform-specific cleanup before secondary CPUs go offline during kexec or reboot. [ ... ] > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c > index 581f80e9b9b73..41c0e98409138 100644 > --- a/arch/arm64/kernel/process.c > +++ b/arch/arm64/kernel/process.c > @@ -88,8 +88,21 @@ void __noreturn arch_cpu_idle_dead(void) [ ... ] > +/* > + * Hook for platform code to perform cleanup after device_shutdown() > + * but before secondary CPUs are offlined. This runs in the kexec path > + * from kernel_kexec() after device_shutdown() and cpu_hotplug_enable() > + * have been called, matching the point at which x86 invokes > + * machine_ops.shutdown. > + */ > +void (*arm64_pre_smp_shutdown_hook)(void); [Severity: Medium] Should this global function pointer be annotated with __ro_after_init? Without it, the pointer resides in writable memory, which could make it a reliable target for control-flow hijacking if an arbitrary memory write primitive is obtained elsewhere. Since the hook is presumably only set once during platform initialization, making it read-only after init would improve defense-in-depth on the shutdown/reboot path. > + > void machine_shutdown(void) > { > + if (arm64_pre_smp_shutdown_hook) > + arm64_pre_smp_shutdown_hook(); > + > smp_shutdown_nonboot_cpus(reboot_cpu); > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
