qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Lidong Chen <lidong.chen@oracle.com>
To: Liam Merwick <liam.merwick@oracle.com>,
	Markus Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Aleksandar Rikalo <arikalo@wavecomp.com>,
	Jason Wang <jasowang@redhat.com>,
	qemu-devel@nongnu.org, f4bug@amsat.org, darren.kenny@oracle.com,
	Gerd Hoffmann <kraxel@redhat.com>,
	Aleksandar Markovic <amarkovic@wavecomp.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	Aurelien Jarno <aurelien@aurel32.net>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH] sd: Fix out-of-bounds assertions
Date: Wed, 10 Apr 2019 14:49:19 -0700	[thread overview]
Message-ID: <e1ccef20-7807-8045-1c69-ae8c1a79cdcd@oracle.com> (raw)
In-Reply-To: <ea798b5f-d48a-c05f-a8cb-d2eb1f6a5a23@oracle.com>

Hi,

Thank you all for the reviews and comments! Since the fixes in sd.c have 
gone through the review, I can fix the issue in util/main-loop.c 
(mentioned in the reviews of Peter and Liam) in a separate patch.

Thanks,

Lidong

On 4/9/2019 3:39 AM, Liam Merwick wrote:
> On 09/04/2019 06:51, Markus Armbruster wrote:
>> Lidong Chen <lidong.chen@oracle.com> writes:
>>
>>> Due to an off-by-one error, the assert statements allow an
>>> out-of-bounds array access.
>>>
>>> Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
>
>
> Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
>
>
>>> ---
>>>   hw/sd/sd.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/hw/sd/sd.c b/hw/sd/sd.c
>>> index aaab15f..818f86c 100644
>>> --- a/hw/sd/sd.c
>>> +++ b/hw/sd/sd.c
>>> @@ -144,7 +144,7 @@ static const char *sd_state_name(enum 
>>> SDCardStates state)
>>>       if (state == sd_inactive_state) {
>>>           return "inactive";
>>>       }
>>> -    assert(state <= ARRAY_SIZE(state_name));
>>> +    assert(state < ARRAY_SIZE(state_name));
>>>       return state_name[state];
>>>   }
>>>   @@ -165,7 +165,7 @@ static const char 
>>> *sd_response_name(sd_rsp_type_t rsp)
>>>       if (rsp == sd_r1b) {
>>>           rsp = sd_r1;
>>>       }
>>> -    assert(rsp <= ARRAY_SIZE(response_name));
>>> +    assert(rsp < ARRAY_SIZE(response_name));
>>>       return response_name[rsp];
>>>   }
>> This is the second fix for this bug pattern in a fortnight. Where's
>> one, there are more:
>
>
> As Lidong mentioned, an internal static analysis tool (Parfait) was 
> used to catch these. Not every arch/board is compiled but I had 
> eyeballed the code of most interest to me and they seemed fine (e.g. 
> for array accesses, the subsequent loops used a less-than check)
>
> However, this WIN32 code in util/main-loop.c seems wrong.
>
> 425     g_assert(n_poll_fds <= ARRAY_SIZE(poll_fds));
> 426
> 427     for (i = 0; i < w->num; i++) {
> 428         poll_fds[n_poll_fds + i].fd = (DWORD_PTR)w->events[i];
> 429         poll_fds[n_poll_fds + i].events = G_IO_IN;
> 430     }
>
> Seems like this should be:
>
> g_assert(n_poll_fds + w->num <= ARRAY_SIZE(poll_fds));
>
> Otherwise, the rest seem fine.
>
> Regards,
>
> Liam
>
>
>>
>> $ git-grep '<= ARRAY_SIZE'
>> hw/intc/arm_gicv3_cpuif.c:    assert(aprmax <= 
>> ARRAY_SIZE(cs->ich_apr[0]));
>> hw/intc/arm_gicv3_cpuif.c:    assert(aprmax <= 
>> ARRAY_SIZE(cs->ich_apr[0]));
>> hw/net/stellaris_enet.c:        if (s->tx_fifo_len + 4 <= 
>> ARRAY_SIZE(s->tx_fifo)) {
>> hw/sd/pxa2xx_mmci.c:        && s->tx_len <= ARRAY_SIZE(s->tx_fifo)
>> hw/sd/pxa2xx_mmci.c:        && s->rx_len <= ARRAY_SIZE(s->rx_fifo)
>> hw/sd/pxa2xx_mmci.c:        && s->resp_len <= ARRAY_SIZE(s->resp_fifo);
>> hw/sd/sd.c:    assert(state <= ARRAY_SIZE(state_name));
>> hw/sd/sd.c:    assert(rsp <= ARRAY_SIZE(response_name));
>> hw/usb/hcd-xhci.c:    assert(n <= ARRAY_SIZE(tmp));
>> target/mips/op_helper.c:    if (base_reglist > 0 && base_reglist <= 
>> ARRAY_SIZE (multiple_regs)) {
>> target/mips/op_helper.c:    if (base_reglist > 0 && base_reglist <= 
>> ARRAY_SIZE (multiple_regs)) {
>> target/mips/op_helper.c:    if (base_reglist > 0 && base_reglist <= 
>> ARRAY_SIZE (multiple_regs)) {
>> target/mips/op_helper.c:    if (base_reglist > 0 && base_reglist <= 
>> ARRAY_SIZE (multiple_regs)) {
>> target/ppc/kvm.c:           <= ARRAY_SIZE(hw_debug_points));
>> target/ppc/kvm.c:           <= ARRAY_SIZE(hw_debug_points));
>> target/ppc/kvm.c:    assert((nb_hw_breakpoint + nb_hw_watchpoint) <= 
>> ARRAY_SIZE(dbg->arch.bp));
>> tcg/tcg.c:    tcg_debug_assert(pi <= ARRAY_SIZE(op->args));
>> util/main-loop.c:    g_assert(n_poll_fds <= ARRAY_SIZE(poll_fds));
>> util/module.c:    assert(n_dirs <= ARRAY_SIZE(dirs));
>>
>> Lidong Chen, would you like to have a look at these?
>>
>> Cc'ing maintainers to help with further investigation.
>>
>

WARNING: multiple messages have this Message-ID (diff)
From: Lidong Chen <lidong.chen@oracle.com>
To: Liam Merwick <liam.merwick@oracle.com>,
	Markus Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Aleksandar Rikalo <arikalo@wavecomp.com>,
	Jason Wang <jasowang@redhat.com>,
	qemu-devel@nongnu.org, f4bug@amsat.org, darren.kenny@oracle.com,
	Gerd Hoffmann <kraxel@redhat.com>,
	Aleksandar Markovic <amarkovic@wavecomp.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	Aurelien Jarno <aurelien@aurel32.net>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH] sd: Fix out-of-bounds assertions
Date: Wed, 10 Apr 2019 14:49:19 -0700	[thread overview]
Message-ID: <e1ccef20-7807-8045-1c69-ae8c1a79cdcd@oracle.com> (raw)
Message-ID: <20190410214919.HUEJyXU78fUrwV3mF4Ypb0DoGYz0g4r52IemmBx9oeU@z> (raw)
In-Reply-To: <ea798b5f-d48a-c05f-a8cb-d2eb1f6a5a23@oracle.com>

Hi,

Thank you all for the reviews and comments! Since the fixes in sd.c have 
gone through the review, I can fix the issue in util/main-loop.c 
(mentioned in the reviews of Peter and Liam) in a separate patch.

Thanks,

Lidong

On 4/9/2019 3:39 AM, Liam Merwick wrote:
> On 09/04/2019 06:51, Markus Armbruster wrote:
>> Lidong Chen <lidong.chen@oracle.com> writes:
>>
>>> Due to an off-by-one error, the assert statements allow an
>>> out-of-bounds array access.
>>>
>>> Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
>
>
> Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
>
>
>>> ---
>>>   hw/sd/sd.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/hw/sd/sd.c b/hw/sd/sd.c
>>> index aaab15f..818f86c 100644
>>> --- a/hw/sd/sd.c
>>> +++ b/hw/sd/sd.c
>>> @@ -144,7 +144,7 @@ static const char *sd_state_name(enum 
>>> SDCardStates state)
>>>       if (state == sd_inactive_state) {
>>>           return "inactive";
>>>       }
>>> -    assert(state <= ARRAY_SIZE(state_name));
>>> +    assert(state < ARRAY_SIZE(state_name));
>>>       return state_name[state];
>>>   }
>>>   @@ -165,7 +165,7 @@ static const char 
>>> *sd_response_name(sd_rsp_type_t rsp)
>>>       if (rsp == sd_r1b) {
>>>           rsp = sd_r1;
>>>       }
>>> -    assert(rsp <= ARRAY_SIZE(response_name));
>>> +    assert(rsp < ARRAY_SIZE(response_name));
>>>       return response_name[rsp];
>>>   }
>> This is the second fix for this bug pattern in a fortnight. Where's
>> one, there are more:
>
>
> As Lidong mentioned, an internal static analysis tool (Parfait) was 
> used to catch these. Not every arch/board is compiled but I had 
> eyeballed the code of most interest to me and they seemed fine (e.g. 
> for array accesses, the subsequent loops used a less-than check)
>
> However, this WIN32 code in util/main-loop.c seems wrong.
>
> 425     g_assert(n_poll_fds <= ARRAY_SIZE(poll_fds));
> 426
> 427     for (i = 0; i < w->num; i++) {
> 428         poll_fds[n_poll_fds + i].fd = (DWORD_PTR)w->events[i];
> 429         poll_fds[n_poll_fds + i].events = G_IO_IN;
> 430     }
>
> Seems like this should be:
>
> g_assert(n_poll_fds + w->num <= ARRAY_SIZE(poll_fds));
>
> Otherwise, the rest seem fine.
>
> Regards,
>
> Liam
>
>
>>
>> $ git-grep '<= ARRAY_SIZE'
>> hw/intc/arm_gicv3_cpuif.c:    assert(aprmax <= 
>> ARRAY_SIZE(cs->ich_apr[0]));
>> hw/intc/arm_gicv3_cpuif.c:    assert(aprmax <= 
>> ARRAY_SIZE(cs->ich_apr[0]));
>> hw/net/stellaris_enet.c:        if (s->tx_fifo_len + 4 <= 
>> ARRAY_SIZE(s->tx_fifo)) {
>> hw/sd/pxa2xx_mmci.c:        && s->tx_len <= ARRAY_SIZE(s->tx_fifo)
>> hw/sd/pxa2xx_mmci.c:        && s->rx_len <= ARRAY_SIZE(s->rx_fifo)
>> hw/sd/pxa2xx_mmci.c:        && s->resp_len <= ARRAY_SIZE(s->resp_fifo);
>> hw/sd/sd.c:    assert(state <= ARRAY_SIZE(state_name));
>> hw/sd/sd.c:    assert(rsp <= ARRAY_SIZE(response_name));
>> hw/usb/hcd-xhci.c:    assert(n <= ARRAY_SIZE(tmp));
>> target/mips/op_helper.c:    if (base_reglist > 0 && base_reglist <= 
>> ARRAY_SIZE (multiple_regs)) {
>> target/mips/op_helper.c:    if (base_reglist > 0 && base_reglist <= 
>> ARRAY_SIZE (multiple_regs)) {
>> target/mips/op_helper.c:    if (base_reglist > 0 && base_reglist <= 
>> ARRAY_SIZE (multiple_regs)) {
>> target/mips/op_helper.c:    if (base_reglist > 0 && base_reglist <= 
>> ARRAY_SIZE (multiple_regs)) {
>> target/ppc/kvm.c:           <= ARRAY_SIZE(hw_debug_points));
>> target/ppc/kvm.c:           <= ARRAY_SIZE(hw_debug_points));
>> target/ppc/kvm.c:    assert((nb_hw_breakpoint + nb_hw_watchpoint) <= 
>> ARRAY_SIZE(dbg->arch.bp));
>> tcg/tcg.c:    tcg_debug_assert(pi <= ARRAY_SIZE(op->args));
>> util/main-loop.c:    g_assert(n_poll_fds <= ARRAY_SIZE(poll_fds));
>> util/module.c:    assert(n_dirs <= ARRAY_SIZE(dirs));
>>
>> Lidong Chen, would you like to have a look at these?
>>
>> Cc'ing maintainers to help with further investigation.
>>
>


  parent reply	other threads:[~2019-04-10 21:52 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-08 19:04 [Qemu-devel] [PATCH] sd: Fix out-of-bounds assertions Lidong Chen
2019-04-08 19:04 ` Lidong Chen
2019-04-08 19:53 ` Marc-André Lureau
2019-04-08 19:53   ` Marc-André Lureau
2019-04-08 21:27 ` Philippe Mathieu-Daudé
2019-04-08 21:27   ` Philippe Mathieu-Daudé
2019-04-08 21:57   ` Lidong Chen
2019-04-08 21:57     ` Lidong Chen
2019-04-09  0:18 ` Li Qiang
2019-04-09  0:18   ` Li Qiang
2019-04-09  5:51 ` Markus Armbruster
2019-04-09  5:51   ` Markus Armbruster
2019-04-09  8:59   ` Aleksandar Markovic
2019-04-09  8:59     ` Aleksandar Markovic
2019-04-09  9:37     ` Philippe Mathieu-Daudé
2019-04-09  9:37       ` Philippe Mathieu-Daudé
2019-04-11 11:52       ` Daniel P. Berrangé
2019-04-11 11:52         ` Daniel P. Berrangé
2019-04-11 12:20         ` Markus Armbruster
2019-04-11 12:20           ` Markus Armbruster
2019-04-11 12:45           ` Daniel P. Berrangé
2019-04-11 12:45             ` Daniel P. Berrangé
2019-04-11 13:25             ` Markus Armbruster
2019-04-11 13:25               ` Markus Armbruster
2019-04-09  9:40   ` Aleksandar Markovic
2019-04-09  9:40     ` Aleksandar Markovic
2019-04-09  9:48   ` Peter Maydell
2019-04-09  9:48     ` Peter Maydell
2019-04-09 10:39   ` Liam Merwick
2019-04-09 10:39     ` Liam Merwick
2019-04-10 21:49     ` Lidong Chen [this message]
2019-04-10 21:49       ` Lidong Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e1ccef20-7807-8045-1c69-ae8c1a79cdcd@oracle.com \
    --to=lidong.chen@oracle.com \
    --cc=amarkovic@wavecomp.com \
    --cc=arikalo@wavecomp.com \
    --cc=armbru@redhat.com \
    --cc=aurelien@aurel32.net \
    --cc=darren.kenny@oracle.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=f4bug@amsat.org \
    --cc=jasowang@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=liam.merwick@oracle.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).