Add advisories for arrow-array, arrow-buffer, arrow-data, arrow-row

[ksj1230]

Seven memory safety issues in Apache Arrow Rust crates, all reachable through safe Rust APIs (#![forbid(unsafe_code)]).

Reported to the Arrow security team and patched in:

• 58.3.0
• 57.3.1
• 56.2.1

Note: These issues were coordinated with the Arrow maintainers, who have completed patch releases. Filing here for ecosystem visibility, as the issues are reachable through safe Rust APIs and can result in out-of-bounds memory access confirmed with AddressSanitizer.

See also the Apache Arrow Rust security policy: https://github.com/apache/arrow-rs/security/policy

[djc]

Did you not see the pull request template content? Or did you just ignore it?

[djc]

Let's get rid of all the code samples, I don't think they're useful here.

I'd like a maintainer to chime in here since I have not seen any maintainer approve the publishing of these advisories.

[djc]

I think this should be informational = "unsound".

[djc]

Make this informational = "unsound".

[djc]

Make this informational = "unsound".

[ksj1230]

For additional context regarding maintainer coordination:
These issues were reported through the ASF security process and coordinated with the Arrow maintainers / PMC prior to publication.
Andrew Lamb (Arrow PMC) confirmed that patch releases for the 56.x, 57.x, and 58.x lines were completed, and also indicated that filing RustSec advisories after the releases was reasonable.
I intentionally waited until the patched releases were published before opening this PR.

I've also addressed the review feedback: added informational = "unsound" to arrow-buffer, arrow-data, and arrow-row, and removed the code samples.

@alamb if you have a moment, could you briefly confirm the release coordination context here?

[alamb]

I'd like a maintainer to chime in here since I have not seen any maintainer approve the publishing of these advisories.

As @ksj1230 states, we did receive their reports and we have released arrow-rs releases with the fixes. The issues are linked below to make it easier to find this PR when needed.

• [arrow-array] Integer overflow in FixedSizeBinaryArray::value leads to undefined behavior apache/arrow-rs#9898
• [arrow-data] Integer overflow in ArrayData::slice leads to undefined behavior apache/arrow-rs#9899
• [arrow-buffer] Integer overflow in BufferBuilder::reserve leads to undefined behavior apache/arrow-rs#9897
• [arrow-data] Integer overflow in ArrayData validation leads to undefined behavior apache/arrow-rs#9900
• [arrow-row] Integer overflow in Rows::row index handling leads to undefined behavior apache/arrow-rs#9901
• [arrow-buffer] Integer overflow in BitChunks::new leads to undefined behavior apache/arrow-rs#9903

After careful analysis against our (newly documented security policy) we determined that none of them is constitutes a Security Vulnerability per our definition

We did backport the fixes and released new versions with the fixes out of an abundance of caution.

As I have opined in this repository before, I personally think the info = "unsound" category in RustSec generates a lot of downstream churn for very little benefit. However, these are real issues in the sense that it is possible to get undefined behavior (out of bounds reads, specifically) with only safe rust code and so does fit this criteria

• Discussion: signal/noise ratio too low? #2572

[djc]

After careful analysis against our (newly documented security policy) we determined that none of them is constitutes a Security Vulnerability per our definition

Sounds good. I'm going to close this.

[alamb]

Thank you for your considered review @djc and thank you very much @ksj1230 for all you help making arrow-rs a safer library

[ksj1230]

@djc Thanks for the clarification and for reviewing this.
I may be misunderstanding the intended scope of informational = "unsound" advisories in RustSec. In #2572, I understood the discussion to suggest that safe-code-reachable UB would generally fit within that category.
Since Andrew confirmed above that these are real UB issues reachable from safe Rust code and that they fit the unsound criteria, I’d be interested in understanding how RustSec currently distinguishes between accepted vs non-accepted informational = "unsound" advisories.