Solvable by turning the usual C library allocation pattern inside-out:
Only the C side allocates, Rust gets views of that memory.
Also well established - calling WebAssembly components requires exactly the same pattern, as the only way to malloc is to call into the WASM side.
The Fil-C side could change the data behind the pointer, which will not reflect on the Rust side due to the copy. Even if you manage to copy back the changes, Fil-C could also persist those pointers in e.g. global memory: at that point you no longer know when it's safe to copy back (or forward) any change.
The only way I can see this work if you cannot pass any Rust-land pointers into Fil-C, but at that point you could also compile the C code to WASM and use the WASM FFI (which has similar restrictions)
WASM is not memory safe in the same sense, in particular, heap corruption vulnerabilities still exist, which could eg. allow bypassing auth, leaking private information etc.
C compiled to WASM is still vulnerable to something like OpenSSL Heartbleed. Fil-C (and CHERI) is not.