Re: [BUG] Potential double-free in Xen dt-overlay attach/remove error path

["Orzel, Michal" <michal.orzel@amd.com>]

Hello,

Thanks for the report.

I will try to book some time next week to investigate the issues. Our DTBO
feature at AMD diverged a bit from the upstream one, so I already planned to do
some work here but as always there are tasks of a higher priority.

~Michal

On 09/04/2026 23:28, Gyujeong Jin wrote:
> 	
> You don't often get email from wlsrbwjd7232@gmail.com. Learn why this is
> important <https://aka.ms/LearnAboutSenderIdentification>
> 	
> 
> Hello Team, I was advised to report this issue in this way because dt-overlay is
> currently experimental and not security supported.
> 
> I would like to report a potential memory safety issue in Xen related to the
> Device Tree overlay handling logic.
> 
> --------------------------------------------------------------------------------
> 
> 
>     Problem Description
> 
> A double-free / use-after-free condition may occur in the dt-overlay handling
> path when an overlay attachment fails and the same overlay is later removed.
> 
> The issue arises because rangeset objects are freed on the failure path of
> handle_attach_overlay_nodes(), but the corresponding pointers are not cleared.
> Subsequently, handle_remove_overlay_nodes() may operate on these stale pointers,
> leading to a second free.
> 
> 
>       Affected Component
> 
>   * Xen ARM
>   * Device Tree overlay subsystem
>   * File: xen/common/device-tree/dt-overlay.c
> 
> Relevant functions:
> 
>   * handle_attach_overlay_nodes()
>   * handle_remove_overlay_nodes()
> 
> 
>       Impact
> 
> This issue may lead to:
> 
>   * Double-free of rangeset structures
>   * Use-after-free when accessing stale pointers
>   * Potential hypervisor crash (DoS)
>   * Possible memory corruption depending on allocator behavior
> 
> Given that this occurs in the hypervisor context, the impact could extend beyond
> a simple crash under certain conditions.
> 
> 
>       Root Cause
> 
> The issue originates from inconsistent memory management between the attach
> failure path and the remove path.
> 
> In handle_attach_overlay_nodes(), the failure path frees rangeset objects:
> 
> |static long handle_attach_overlay_nodes(...) { ... if ( entry )
> { rangeset_destroy(entry->irq_ranges); rangeset_destroy(entry->iomem_ranges); }
> return rc; } |
> 
> However, the corresponding pointers (entry->irq_ranges and entry->iomem_ranges)
> are not set to NULL afterward, leaving dangling pointers in the entry structure.
> 
> Later, in handle_remove_overlay_nodes(), the same fields are used again:
> 
> |static long handle_remove_overlay_nodes(const void *overlay_fdt, uint32_t
> overlay_fdt_size) { ... rc = remove_nodes(entry); ... rangeset_destroy(entry-
>>irq_ranges); rangeset_destroy(entry->iomem_ranges); ... } static int
> remove_nodes(const struct overlay_track *tracker) { /* Remove IRQ access. */ if
> ( tracker->irq_ranges ) { rc = rangeset_consume_ranges(tracker->irq_ranges,
> irq_remove_cb, d); if ( rc ) return rc; } /* Remove mmio access. */ if
> ( tracker->iomem_ranges ) { rc = rangeset_consume_ranges(tracker->iomem_ranges,
> iomem_remove_cb, d); if ( rc ) return rc; } return rc; } |
> 
> Since the pointers were not invalidated after being freed, this leads to:
> 
>   * reuse of freed memory in rangeset_consume_ranges()
>   * double-free in rangeset_destroy()
> 
> This creates a double-free / use-after-free condition.
> 
> 
>       Environment
> 
>   * Xen: 4.22-dev-517-g500ee5fe0f
>   * Platform: Linux (WSL2 environment)
> 
> 
>     Suggested Fix
> 
> After calling rangeset_destroy(), the corresponding pointers should be set to
> NULL to prevent reuse:
> 
> |entry->irq_ranges = NULL; entry->iomem_ranges = NULL; |
> 
> Alternatively, the remove path should defensively check pointer validity.
> 
> Best regards, Gyujeong Jin (Giunash)
>