It reminds me another similar issue:
http://openvswitch.org/pipermail/dev/2016-March/067313.html
Is there some way to avoid or make it harder to forgetting to update the
pointer once ofpbuf_put_uninit reallocate to newly allocated memory?
Regards,
William
On Tue, Apr 12, 2016 at 10:00 PM, Ben
On Mon, Mar 07, 2016 at 11:12:40AM -0800, Joe Stringer wrote:
> As a separate thing, I was wondering about whether it's worthwhile to
> do something additional to try to avoid this kind of bug in future. A
> couple of ideas:
> * Rearrange the parse/decode functions so that ofpact_finish() is the
>
Oh! I've been looking mostly at v2.5 lately and didn't notice how
commit 2bd318dec2428ae6c0febbf79453982676ccb672 changed the
"update_len" (now ofpact_finish) function.
Thanks, I applied this to master.
As a separate thing, I was wondering about whether it's worthwhile to
do something additional
Hi Joe,
Thanks for your reply. The reason is that line 181:
ofpact_finish(ofpacts, >ofpact);
https://github.com/openvswitch/ovs/blob/34abaa3deaa430ca0b50453865d2e042a5132165/lib/bundle.c#L181
Could also call into ofpbuf_put_zero, which frees the memory pointed by
bundle.
Regards,
William
On 4 March 2016 at 18:00, William Tu wrote:
> Address pointed by bundle could be obsolete/free'd when
> realloc, called from ofpbuf_put_zero(), returns new address.
> Reported by Valgrind 367: ovs-ofctl parse-flows (NXM)
>
> Invalid write of size 4
> bundle_parse__
Address pointed by bundle could be obsolete/free'd when
realloc, called from ofpbuf_put_zero(), returns new address.
Reported by Valgrind 367: ovs-ofctl parse-flows (NXM)
Invalid write of size 4
bundle_parse__ (bundle.c:200)
bundle_parse_load (bundle.c:272)
parse_bundle_load