CVE-2023-53627

The issue arises because of missing locking when accessing the shared sas_dev.list structure. Two code paths can execute concurrently: the completion queue thread (cq thread) calls slot_complete_v3_hw() → hisi_sas_slot_task_free() → list_del_init() to remove completed task slots, while the SCSI error handler thread calls sas_scsi_find_task() → hisi_sas_abort_task() → dereg_device_v3_hw() → list_for_each_entry_safe() to traverse the same list when aborting tasks. Without synchronization, the deletion can invalidate list pointers while traversal is in progress. When the error handler attempts to follow the next pointer in the list after a concurrent deletion, it dereferences a NULL or freed pointer (register x1 = 0x0000000000000000 in the crash dump), causing a kernel panic. The race window is narrow and requires precise timing between I/O completion and error handling paths, which can be triggered under heavy I/O workload with concurrent errors. While this reliably causes availability impact through kernel panics, the underlying list corruption represents a memory safety violation. With sufficient control over timing and heap layout, race conditions on linked list structures can potentially be leveraged for more sophisticated attacks beyond denial of service, though such exploitation would be complex.