[Guy Harris <gharris@xxxxxxxxx>]

On Apr 16, 2026, at 11:50 PM, Cristina Dinu <cristina.dinu@xxxxxxxxxxxxxx> wrote:

> Any idea what causes this? It might be a broken packet that breaks the dissector we use (dspace-group
> dsV2Gshark)

If a bad packet causes a crash in a dissector, that dissector is *inherently* broken. Dissectors should never crash; if they do, that's called a "bug".

The crash is in a routine named _platform_strlen (), called from l_decodeV2GExi(), which is being called by Lua code using a foreign function interface, so there's probably either a bug in a Lua dissector, where it's not checking for the validity of what it's providing to that routine, or in that routine itself.

That routine, in the tip-of-the-main-branch version of that plugin, looks fairly simple:

static int l_decodeV2GExiAuto(lua_State *L)
{
    std::string exiIn = luaL_checkstring(L, 1);

    result_decode result = v2g_message_decoder.decode_message_auto_schema(exiIn);
    if (result.errn != EXI_ERROR__NO_ERROR)
    {
        lua_pushnil(L);
        lua_pushnil(L);
        lua_pushnil(L);
        return 3;
    }
    else
    {
        lua_pushstring(L, result.decoded_xml.c_str());
        lua_pushstring(L, result.used_schema.c_str());
        lua_pushinteger(L, result.errn);
        return 3;
    }
}

The crash itself is in _platform_strlen(), which means that the C/C++ library routine strlen() is being called; the crash is probably because it's being passed a null pointer.

That routine isn't *directly* calling strlen(), so I'm guessing that one of the methods it calls is being inlined.

You should probably report this to the developers of the plugin, so that they can find the bug and fix it.