xtensa: ptables: fix dangling memory domains#106923
xtensa: ptables: fix dangling memory domains#106923nashif merged 1 commit intozephyrproject-rtos:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Fixes an Xtensa memory-domain lifecycle issue where deinitialized domains could remain in the global Xtensa domain list, leading to potential use-after-free when the list is traversed later.
Changes:
- Remove the deinitialized domain’s list node from
xtensa_domain_listduringarch_mem_domain_deinit().
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| sys_slist_find_and_remove(&xtensa_domain_list, &domain->arch.node); | ||
|
|
||
| k_spin_unlock(&xtensa_mmu_lock, key); |
There was a problem hiding this comment.
Potential lock-order inversion: k_mem_domain_deinit() holds z_mem_domain_lock while calling arch_mem_domain_deinit(), which takes xtensa_mmu_lock; meanwhile arch_mem_map()/arch_mem_unmap() take xtensa_mmu_lock and then z_mem_domain_lock while iterating xtensa_domain_list. This can deadlock on SMP. Consider removing the inner z_mem_domain_lock usage in __arch_mem_map/__arch_mem_unmap (xtensa_mmu_lock already serializes xtensa_domain_list), or otherwise standardize acquisition order to z_mem_domain_lock -> xtensa_mmu_lock across all paths.
There was a problem hiding this comment.
this is a problem indeed, but it was there before this commit too. Let me open a bug. #106925
When a memory domain is freed on Xtensa, it also has to be removed from the global domain list. Leaving it on the list can cause use-after-free exceptions. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
|
|
@nashif @dcpleung do I understand it correctly that the SonarCloud failure https://github.com/zephyrproject-rtos/zephyr/pull/106923/checks?check_run_id=70263251619 is a false positive, since it only complains about lines in the file that this PR isn't touching? |
|
I would say so. |
When a memory domain is freed on Xtensa, it also has to be removed from the global domain list. Leaving it on the list can cause use-after-free exceptions.