[Rust] Verifier fails to detect invalid flatbuffer involving structs of the wrong type
TheButlah opened this issue · comments
Incorrectly serializing some flatbuffer code in Java like this: https://github.com/SlimeVR/SlimeVR-Server/blob/6d940503af38ab1ff07742864093c798711d7bc6/src/main/java/dev/slimevr/protocol/DataFeedBuilder.java#L120
Schema is here: https://github.com/SlimeVR/SolarXR-Protocol/blob/88d9f7060cdf4c28210fa0138359adf5b768e9fc/protocol/flatbuffers/data_feed/tracker.fbs#L19
Deserializing in rust using the built-in flatbuffer verifier from flatbuffers v2.1.1 (and the code was generated with a flatc from very recently, near main). No error is detected, which is unexpected as I'm assigning a Vec3f struct to a Quat struct, which ought to be invalid.
The verifier has detected issues with tables of incompatible types successfully in the past, so this is likely related to the fact that I'm mixing up two structs of floats. Perhaps structs have something about them the verifier fails to check?
From a binary perspective structs are just fixed sized binary blobs. The only thing we can do to tell its invalid is check the pointer to the struct and the pointer + size of struct aren't out of bounds. It's not like we have any sentinels that indicate the struct's type that we could check.
In this case the structs are different sizes so it should be possible, right?
Not really. We can't tell how big the struct from the binary. We could keep track of every byte and disallow bytes where structs overlap with other data-structures. That'd be pretty complex and slow in practice. Also, that would potentially disallow existing data as it's already legal for the same byte to be referenced in multiple places: strings and tables definitely can be referenced from multiple locations. I think it might be possible for structs too, which can be stored by offset in unions.