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

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

[Gyujeong Jin]

[-- Attachment #1: Type: text/plain, Size: 3249 bytes --]

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)

[-- Attachment #2: Type: text/html, Size: 4020 bytes --]

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

[Jan Beulich]

On 09.04.2026 23:28, Gyujeong Jin wrote:
> 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.

Further to this, am I overlooking any check preventing an already created
pair of rangesets to be replaced by new ones, leaking the original pair?

And then there's a Misra issue as well: dt_overlay_domctl() has unreachable
code. Anything other than XEN_DOMCTL_DT_OVERLAY_ATTACH is excluded at the
top, so the "else" body near the bottom is unreachable. (This in turn makes
me wonder: How come there's no "detach"?) Yet then, that's probably pretty
meaningless, as there look to be other issues (Misra and general robustness
ones) as well.

Jan

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

[Nicola Vetrini]

On 2026-04-10 08:31, Jan Beulich wrote:
> On 09.04.2026 23:28, Gyujeong Jin wrote:
>> 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.
> 
> Further to this, am I overlooking any check preventing an already 
> created
> pair of rangesets to be replaced by new ones, leaking the original 
> pair?
> 
> And then there's a Misra issue as well: dt_overlay_domctl() has 
> unreachable
> code. Anything other than XEN_DOMCTL_DT_OVERLAY_ATTACH is excluded at 
> the
> top, so the "else" body near the bottom is unreachable. (This in turn 
> makes
> me wonder: How come there's no "detach"?) Yet then, that's probably 
> pretty
> meaningless, as there look to be other issues (Misra and general 
> robustness
> ones) as well.
> 
> Jan

Is it by any chance enabled in *-allcode analyses? I don't see such 
reports for unreachable code on ARM64.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

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

[Andrew Cooper]

On 10/04/2026 11:06 am, Nicola Vetrini wrote:
> On 2026-04-10 08:31, Jan Beulich wrote:
>> On 09.04.2026 23:28, Gyujeong Jin wrote:
>>> 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.
>>
>> Further to this, am I overlooking any check preventing an already
>> created
>> pair of rangesets to be replaced by new ones, leaking the original pair?
>>
>> And then there's a Misra issue as well: dt_overlay_domctl() has
>> unreachable
>> code. Anything other than XEN_DOMCTL_DT_OVERLAY_ATTACH is excluded at
>> the
>> top, so the "else" body near the bottom is unreachable. (This in turn
>> makes
>> me wonder: How come there's no "detach"?) Yet then, that's probably
>> pretty
>> meaningless, as there look to be other issues (Misra and general
>> robustness
>> ones) as well.
>>
>> Jan
>
> Is it by any chance enabled in *-allcode analyses? I don't see such
> reports for unreachable code on ARM64.
>

eclair-ARM64-allcode:
    ...
    EXTRA_XEN_CONFIG: |
        ...
        CONFIG_OVERLAY_DTB=y

Seems to be, yes.

~Andrew

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

[Orzel, Michal]

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)
>