It's really just shown as a string, and doesn't actually refer to packet data from a tvbuff.
This is causing at least one crash in bug 12335:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12335
and, to fix the crash I'm seeing, we'd have to change the epan/ftypes/ftype-tvbuff.c cmp_contains() routines to check for the field not actually having a tvbuff and treating it as a string comparison instead. Furthermore, all the *other* routines that assume a tvbuff would *also* have to be changed to handle a null tvbuff, to prevent similar crashes in other cases.
