On 2/6/20 7:32 PM, Guenter Roeck wrote: > Whenever an unsupported command is encountered, the current code > interprets each transferred byte as new command. Most of the time, those > 'commands' are interpreted as new unknown commands. However, in rare > cases, it may be that for example address or length information > passed with the original command is by itself a valid command. > If that happens, the state machine may get completely confused and, > worst case, start writing data into the flash or even erase it. > > To avoid the problem, transition into STATE_READING_DATA and keep > sending a value of 0 until the chip is deselected after encountering > an unsupported command. > > Signed-off-by: Guenter Roeck <li...@roeck-us.net>
Reviewed-by: Cédric Le Goater <c...@kaod.org> > --- > v2: Split patch into two parts; improved description. > > hw/block/m25p80.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c > index 53bf63856f..8227088441 100644 > --- a/hw/block/m25p80.c > +++ b/hw/block/m25p80.c > @@ -1161,6 +1161,11 @@ static void decode_new_cmd(Flash *s, uint32_t value) > s->quad_enable = false; > break; > default: > + s->pos = 0; > + s->len = 1; > + s->state = STATE_READING_DATA; > + s->data_read_loop = true; > + s->data[0] = 0; > qemu_log_mask(LOG_GUEST_ERROR, "M25P80: Unknown cmd %x\n", value); > break; > } >
