Re: [PATCH-for-6.1 2/3] hw/sd/sdcard: Fix assertion accessing out-of-range addresses with CMD30

[Philippe Mathieu-Daudé]

On 8/2/21 2:03 PM, Peter Maydell wrote:
> On Wed, 28 Jul 2021 at 19:19, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> OSS-Fuzz found sending illegal addresses when querying the write
>> protection bits triggers the assertion added in commit 84816fb63e5
>> ("hw/sd/sdcard: Assert if accessing an illegal group"):
>>
>>   qemu-fuzz-i386-target-generic-fuzz-sdhci-v3: ../hw/sd/sd.c:824: uint32_t 
>> sd_wpbits(SDState *, uint64_t):
>>   Assertion `wpnum < sd->wpgrps_size' failed.
>>   #3 0x7f62a8b22c91 in __assert_fail
>>   #4 0x5569adcec405 in sd_wpbits hw/sd/sd.c:824:9
>>   #5 0x5569adce5f6d in sd_normal_command hw/sd/sd.c:1389:38
>>   #6 0x5569adce3870 in sd_do_command hw/sd/sd.c:1737:17
>>   #7 0x5569adcf1566 in sdbus_do_command hw/sd/core.c:100:16
>>   #8 0x5569adcfc192 in sdhci_send_command hw/sd/sdhci.c:337:12
>>   #9 0x5569adcfa3a3 in sdhci_write hw/sd/sdhci.c:1186:9
>>   #10 0x5569adfb3447 in memory_region_write_accessor softmmu/memory.c:492:5
>>
>> It is legal for the CMD30 to query for out-of-range addresses.
>> Such invalid addresses are simply ignored in the response (write
>> protection bits set to 0).
>>
>> Note, we had an off-by-one in the wpgrps_size check since commit
>> a1bb27b1e98. Since we have a total of 'wpgrps_size' bits, the latest
>> valid group bit is 'wpgrps_size - 1'.
> 
> The commit message says "wpgrps_size - 1" is valid...
> 
>> @@ -820,8 +820,8 @@ static uint32_t sd_wpbits(SDState *sd, uint64_t addr)
>>
>>      wpnum = sd_addr_to_wpnum(addr);
>>
>> -    for (i = 0; i < 32; i++, wpnum++, addr += WPGROUP_SIZE) {
>> -        assert(wpnum < sd->wpgrps_size);
>> +    for (i = 0; i < 32 && wpnum < sd->wpgrps_size - 1;
> 
> ...but the code change makes the loop terminate when
> wpnum == wpgrps_size - 1, so we don't execute the loop
> body for wpgrps_size -1.
> 
> Which is correct ?

The problem is in sd_reset(), this code is hard for me to follow
(and I plan to refactor it during next dev cycle):

        blk_get_geometry(sd->blk, &sect);
    size = sect << 9;
    sect = sd_addr_to_wpnum(size) + 1;
    sd->wpgrps_size = sect;
    sd->wp_groups = bitmap_new(sd->wpgrps_size);

CID.WP_GRP_SIZE is defined as:

  The size of a write protected group. The content of this register
  is a 7-bit binary coded value, defining the number of erase sectors
  (see SECTOR_SIZE). The actual size is computed by increasing this
  number by one. A value of zero means one erase sector, 127 means
  128 erase sectors.

I think there is a confusion, wpgrps_size holds the real number of erase
sectors (used by the model, not returned in the CID.WP_GRP_SIZE
register). CID.WP_GRP_SIZE should be (wpgrps_size - 1).

Currently we iterate 1 sector number outside of the flash area.
To avoid that I used 'wpnum < sd->wpgrps_size - 1' instead of
'wpnum <= sd->wpgrps_size - 1'.

But with the fix you suggested responding to the cover, we don't hit
this case anymore. So I'll take it and clean the rest later.

Thanks,

Phil.

> 
>> +                i++, wpnum++, addr += WPGROUP_SIZE) {
> 
> thanks
> -- PMM
>