On 8/2/21 2:03 PM, Peter Maydell wrote:
> On Wed, 28 Jul 2021 at 19:19, Philippe Mathieu-Daudé <f4...@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, §);
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
>
