hw/adc: Fix out-of-bounds write in Aspeed ADC model

[PATCH] hw/adc: Fix out-of-bounds write in Aspeed ADC model

Posted by Cédric Le Goater 1 week, 4 days ago

The 'regs' array has ASPEED_ADC_NR_REGS (52) elements, while the
memory region covers offsets 0x00-0xFC. The aspeed_adc_engine_write()
function has an out-of-bounds write vulnerability when accessing
unimplemented registers.

Fix this by using 'return' instead of 'break' in the default case,
which prevents execution from reaching the s->regs[reg] assignment for
unimplemented registers.

Reported-by: Elhrj Saad <saadelhrj@gmail.com>
Fixes: 5857974d5d11 ("hw/adc: Add basic Aspeed ADC model")
Signed-off-by: Cédric Le Goater <clg@redhat.com>
---
 hw/adc/aspeed_adc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/adc/aspeed_adc.c b/hw/adc/aspeed_adc.c
index fd3af308296e..3cc75bbcd6e2 100644
--- a/hw/adc/aspeed_adc.c
+++ b/hw/adc/aspeed_adc.c
@@ -228,7 +228,8 @@ static void aspeed_adc_engine_write(void *opaque, hwaddr addr, uint64_t value,
         qemu_log_mask(LOG_UNIMP, "%s: engine[%u]: "
                       "0x%" HWADDR_PRIx " 0x%" PRIx64 "\n",
                       __func__, s->engine_id, addr, value);
-        break;
+        /* Do not update the regs[] array */
+        return;
     }
 
     s->regs[reg] = value;
-- 
2.52.0

Re: [PATCH] hw/adc: Fix out-of-bounds write in Aspeed ADC model

Posted by Michael Tokarev 1 day, 7 hours ago

On 1/26/26 17:18, Cédric Le Goater wrote:
> The 'regs' array has ASPEED_ADC_NR_REGS (52) elements, while the
> memory region covers offsets 0x00-0xFC. The aspeed_adc_engine_write()
> function has an out-of-bounds write vulnerability when accessing
> unimplemented registers.
> 
> Fix this by using 'return' instead of 'break' in the default case,
> which prevents execution from reaching the s->regs[reg] assignment for
> unimplemented registers.
> 
> Reported-by: Elhrj Saad <saadelhrj@gmail.com>
> Fixes: 5857974d5d11 ("hw/adc: Add basic Aspeed ADC model")
> Signed-off-by: Cédric Le Goater <clg@redhat.com>
> ---
>   hw/adc/aspeed_adc.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)

This feels like a qemu-stable material.

Please let me know if it isn't.

Thanks,

/mjt

> diff --git a/hw/adc/aspeed_adc.c b/hw/adc/aspeed_adc.c
> index fd3af308296e..3cc75bbcd6e2 100644
> --- a/hw/adc/aspeed_adc.c
> +++ b/hw/adc/aspeed_adc.c
> @@ -228,7 +228,8 @@ static void aspeed_adc_engine_write(void *opaque, hwaddr addr, uint64_t value,
>           qemu_log_mask(LOG_UNIMP, "%s: engine[%u]: "
>                         "0x%" HWADDR_PRIx " 0x%" PRIx64 "\n",
>                         __func__, s->engine_id, addr, value);
> -        break;
> +        /* Do not update the regs[] array */
> +        return;
>       }
>   
>       s->regs[reg] = value;

Re: [PATCH] hw/adc: Fix out-of-bounds write in Aspeed ADC model

Posted by Philippe Mathieu-Daudé 1 week, 4 days ago

On 26/1/26 15:18, Cédric Le Goater wrote:
> The 'regs' array has ASPEED_ADC_NR_REGS (52) elements, while the
> memory region covers offsets 0x00-0xFC. The aspeed_adc_engine_write()
> function has an out-of-bounds write vulnerability when accessing
> unimplemented registers.
> 
> Fix this by using 'return' instead of 'break' in the default case,
> which prevents execution from reaching the s->regs[reg] assignment for
> unimplemented registers.
> 
> Reported-by: Elhrj Saad <saadelhrj@gmail.com>
> Fixes: 5857974d5d11 ("hw/adc: Add basic Aspeed ADC model")
> Signed-off-by: Cédric Le Goater <clg@redhat.com>
> ---
>   hw/adc/aspeed_adc.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH] hw/adc: Fix out-of-bounds write in Aspeed ADC model

Posted by Peter Maydell 1 week, 4 days ago

On Mon, 26 Jan 2026 at 14:18, Cédric Le Goater <clg@redhat.com> wrote:
>
> The 'regs' array has ASPEED_ADC_NR_REGS (52) elements, while the
> memory region covers offsets 0x00-0xFC. The aspeed_adc_engine_write()
> function has an out-of-bounds write vulnerability when accessing
> unimplemented registers.
>
> Fix this by using 'return' instead of 'break' in the default case,
> which prevents execution from reaching the s->regs[reg] assignment for
> unimplemented registers.
>
> Reported-by: Elhrj Saad <saadelhrj@gmail.com>
> Fixes: 5857974d5d11 ("hw/adc: Add basic Aspeed ADC model")
> Signed-off-by: Cédric Le Goater <clg@redhat.com>

Seems like a good candidate for Cc: qemu-stable@nongnu.org ?

thanks
-- PMM

Re: [PATCH] hw/adc: Fix out-of-bounds write in Aspeed ADC model

Posted by Cédric Le Goater 1 week, 4 days ago

On 1/26/26 15:30, Peter Maydell wrote:
> On Mon, 26 Jan 2026 at 14:18, Cédric Le Goater <clg@redhat.com> wrote:
>>
>> The 'regs' array has ASPEED_ADC_NR_REGS (52) elements, while the
>> memory region covers offsets 0x00-0xFC. The aspeed_adc_engine_write()
>> function has an out-of-bounds write vulnerability when accessing
>> unimplemented registers.
>>
>> Fix this by using 'return' instead of 'break' in the default case,
>> which prevents execution from reaching the s->regs[reg] assignment for
>> unimplemented registers.
>>
>> Reported-by: Elhrj Saad <saadelhrj@gmail.com>
>> Fixes: 5857974d5d11 ("hw/adc: Add basic Aspeed ADC model")
>> Signed-off-by: Cédric Le Goater <clg@redhat.com>
> 
> Seems like a good candidate for Cc: qemu-stable@nongnu.org ?
Yes.

Cc: qemu-stable@nongnu.org

Thanks,

C.

Re: [PATCH] hw/adc: Fix out-of-bounds write in Aspeed ADC model

Posted by Elhrj Saad 1 week, 4 days ago

Hello, gentlemen,

Is there any possibility of making an exception and assigning a CVE for the
issue ?? (It's my first ever found vulnerability :)

Thank you in advance.


On Mon, Jan 26, 2026 at 4:12 PM Cédric Le Goater <clg@redhat.com> wrote:

> On 1/26/26 15:30, Peter Maydell wrote:
> > On Mon, 26 Jan 2026 at 14:18, Cédric Le Goater <clg@redhat.com> wrote:
> >>
> >> The 'regs' array has ASPEED_ADC_NR_REGS (52) elements, while the
> >> memory region covers offsets 0x00-0xFC. The aspeed_adc_engine_write()
> >> function has an out-of-bounds write vulnerability when accessing
> >> unimplemented registers.
> >>
> >> Fix this by using 'return' instead of 'break' in the default case,
> >> which prevents execution from reaching the s->regs[reg] assignment for
> >> unimplemented registers.
> >>
> >> Reported-by: Elhrj Saad <saadelhrj@gmail.com>
> >> Fixes: 5857974d5d11 ("hw/adc: Add basic Aspeed ADC model")
> >> Signed-off-by: Cédric Le Goater <clg@redhat.com>
> >
> > Seems like a good candidate for Cc: qemu-stable@nongnu.org ?
> Yes.
>
> Cc: qemu-stable@nongnu.org
>
> Thanks,
>
> C.
>
>

-- 
*Saad ELHARAJ*
Cybersecurity Specialist
📞 +212 6 80 51 11 85
✉️ saadelhrj@gmail.com
🔗 LinkedIn <https://www.linkedin.com/in/saad-elharaj-1891371a0/>

Re: [PATCH] hw/adc: Fix out-of-bounds write in Aspeed ADC model

Posted by Daniel P. Berrangé 1 week, 3 days ago

On Mon, Jan 26, 2026 at 07:22:23PM +0100, Elhrj Saad wrote:
> Hello, gentlemen,
> 
> Is there any possibility of making an exception and assigning a CVE for the
> issue ?? (It's my first ever found vulnerability :)

Thank you for your contribution to improving the quality of QEMU. In many
projects this would indeed qualify for assignment of a CVE, but as Peter
mentions, this falls outside the scope of QEMU's security policy.

Assigning CVEs has quite a ripple effect on those consuming QEMU, due
to it triggering many security response processes. As such we do not
wish to issue CVEs for things that the project considers to merely be
hardening bug fixes in an area of code that is not designed to be
providing a security boundary.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] hw/adc: Fix out-of-bounds write in Aspeed ADC model

Posted by Peter Maydell 1 week, 4 days ago

On Mon, 26 Jan 2026 at 18:22, Elhrj Saad <saadelhrj@gmail.com> wrote:
> Is there any possibility of making an exception and assigning
> a CVE for the issue ?? (It's my first ever found vulnerability :)

Hi; this is not a security vulnerability according to QEMU's
security policy, which you can find here:
https://www.qemu.org/docs/master/system/security.html

The board that uses this device is not one usable under
the "virtualization" use case, and so we do not consider
that bugs in it are security issues. So it's not a
"vulnerability", just a normal bug, and we would not
issue a CVE for it.

thanks
-- PMM