Fix recursive tcpedit cleanup #855
Conversation
Assume a single tcpedit struct and return the previously allocated context. This fixes an issue with the Juniper Encapsulated Ethernet DLT plugin which has an exception in the way the plugins works with regard to the extra buffer in question: tcpreplay works with the assumption that there only ever is a single link layer plugin which is mostly true except here: Juniper has a special call to tcpedit_dlt_copy_decoder_state() which causes the ctx and subctx to share a reference to the decoded_extra buffer, and a double free. Fixes: appneta#813 appneta#850
|
Hi, Is it possible this is some configuration issue ? The normal build works fine. |
In 4.5.0 I made it so that the linter never fails, but it will still put inline suggestions in the PR. If the code quality goes up, I can restore the CI failure. |
|
Thanks for the PR. Will merge to 4.5.0 now and then test before release. |
It seems I messed up. The assumption that there's a single tcpedit struct is probably wrong in some situations. |
|
Not a problem. I much prefer getting help and becoming a tester than hunting down problems on my own. Your contributions are always welcome. |
Assume a single tcpedit struct and return the previously allocated context if called twice.
This fixes an issue with the Juniper Encapsulated Ethernet DLT plugin which has an exception in the way the plugins works with regard to the extra buffer in question: tcpreplay works with the assumption that there only ever is a single link layer plugin which is mostly true except here: Juniper has a special call to tcpedit_dlt_copy_decoder_state() which causes the ctx and subctx to share a reference to the decoded_extra buffer, and a double free.
Fixes: #813 #850