bit2swaz opened a new issue, #10679: URL: https://github.com/apache/arrow-rs/issues/10679
### Describe the bug `FFI_ArrowSchema::with_metadata` casts `self.private_data` to `*mut SchemaPrivateData` and writes through it, without checking that arrow-rs built the schema: [ffi.rs#L245](https://github.com/apache/arrow-rs/blob/c87638f4a977c289395725bb329cf33fb4e8fc44/arrow-schema/src/ffi.rs#L245) for a schema imported over FFI (from Java, C++, pyarrow, etc.) `private_data` is the producer's own struct, not a `SchemaPrivateData`. so that cast reinterprets foreign bytes as a Rust type and writes to them, which is UB. `with_metadata` is safe public api, so this is reachable from safe code. [with_name](https://github.com/apache/arrow-rs/blob/c87638f4a977c289395725bb329cf33fb4e8fc44/arrow-schema/src/ffi.rs#L178) is fine today since it only overwrites `self.name`, but it leaks the old name pointer to avoid touching `private_data`. fixing that leak would hit the same problem. came out of the #10431 review thread, credits to @ashdnazg for spotting it ### To Reproduce import any schema over the C Data Interface (so `private_data` isnt a `SchemaPrivateData`), then call `.with_metadata(...)` on it ### Expected behavior calling `with_metadata` on a foreign schema shouldnt be UB. two ways to close it: - A: make `with_metadata` (and `with_name`) `unsafe`. it's honest about the precondition and costs nothing at runtime, but it breaks the safe api. - B: detect foreign schemas and return `Err` instead of casting, keeping the methods safe. a local schema always has `release == Some(release_schema)` (set in `try_new`), and a foreign one carries the producer's release, so that comparison tells them apart with no new field or abi change. i lean B since it keeps the API safe and non breaking ### Additional context follow-up to #10431. happy to put up the PR once the direction is picked :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
