On Wed, Nov 23, 2022 at 10:23:37PM +0100, Ilya Maximets wrote:
> The value is right-justified after the string parsing with
> parse_int_string(), i.e. it is in BE byte order and aligned
> to the right side of the array.
>
> For example, the 0x10011 value in a 4-byte field will look
> like 0x00 0x01 0x00 0x11.
>
> However, value copy to the resulted ofpact is performed
> from the start of the memory. So, in case the destination
> size is smaller than the original field size, incorrect
> part of the value will be copied.
>
> In the 0x00 0x01 0x00 0x11 example above, if the copy is
> performed to a 3-byte field, the first 3 bytes will be
> copied, which are 0x00 0x01 0x00 instead of 0x01 0x00 0x11.
>
> This leads to a problem where NXM_NX_REG3[0..16]=0x10011
> turns into NXM_NX_REG3[0..16]=0x100 after the parsing.
>
> Fix that by offsetting the starting position to the size
> difference in bytes similarly to how it is done in
> learn_parse_load_immediate().
>
> While at it, changing &imm to imm.b in function calls that
> expect byte arrays as an argument. The old way is technically
> correct, but more error prone.
>
> The mf_write_subfield_value() call was also incorrect.
> However, the 'match' variable is actually not used for
> anything since checking removal in commit:
>
> dd43a558597b ("Do not perform validation in learn_parse();")
>
> So, just removing the call and the 'match' variable
> entirely instead of fixing it.
>
> Fixes: 21b2fa617126 ("ofp-parse: Allow match field names in actions and
> brackets in matches.")
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2022-November/052100.html
> Reported-by: Thomas Lee <[email protected]>
> Signed-off-by: Ilya Maximets <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
