GH-54025: [C++][Engine] Validate Substrait emit output_mapping indices

[Nayana-Naik73]

• GitHub Issue: [C++][Engine] Out-of-bounds read on invalid Substrait emit output_mapping index #54025

Rationale for this change

While reading the Substrait relation conversion I noticed that GetEmitInfo and ProcessEmitProject take the emit.output_mapping values straight from the plan and use them to index input_schema->field(map_id) and the project expression vector, with no range check. Schema::field only has debug assertions, so a deserialised plan carrying an out-of-bounds or negative mapping index reads past the end of those vectors (and in the project case moves an out-of-bounds compute::Expression). This is reachable from the public DeserializePlan entry point, which parses untrusted plan bytes, and it applies to essentially every relation kind that goes through the emit path. The neighbouring ProcessExtensionEmit already range-checks the same index, so the two emit helpers were simply missing the equivalent guard.

What changes are included in this PR?

A range check on map_id in both GetEmitInfo and ProcessEmitProject that returns Status::Invalid for negative or out-of-bounds indices, matching the existing check in ProcessExtensionEmit. For a ProjectRel the emit input schema and the project expression vector are the same length by construction (input columns are prefixed as passthrough refs), so the single num_fields() bound covers both accesses.

Are these changes tested?

Yes. Added ReadRelWithOutOfBoundsEmit and ProjectRelWithOutOfBoundsEmit to serde_test.cc, which deserialise plans with negative and out-of-range outputMapping indices through the generic emit path (ReadRel) and the ProjectRel path and expect Status::Invalid. Without the fix both tests hit the Schema::field DCHECK in a debug build. The existing emit round-trip tests still cover the valid-index path.

Are there any user-facing changes?

Deserialising a Substrait plan whose emit output_mapping contains a negative or out-of-range index now returns Status::Invalid rather than reading out of bounds. Valid plans are unaffected.

This PR contains a "Critical Fix". It prevents an out-of-bounds read (and an out-of-bounds object move) when converting an untrusted Substrait plan with a malformed emit output_mapping.

Was AI used for this PR?

In accordance to the AI generation guidelines, please disclose below whether and how AI was used in this PR.

PR code and description written by:

• Human
• AI

Reviewed before submission by:

• Human
• AI
• Not reviewed

[Reranko05]

@Nayana-Naik73 I don't think this is an MINOR PR, could you perhaps open an issue for this.

[dmitry-chirkov-dremio]

The bounds checks look correct and consistently cover both emit paths. However, given that this fixes an untrusted-input memory-safety issue, the ASan reproducer is not a substitute for regression coverage.
Let's add tests verifying that negative and out-of-range output_mapping indices return Status::Invalid through both the generic and ProjectRel paths.

[Nayana-Naik73]

@Reranko05 fair enough, I've opened #54025 for it and retitled the PR to match.

@dmitry-chirkov-dremio added ReadRelWithOutOfBoundsEmit and ProjectRelWithOutOfBoundsEmit to serde_test.cc. Each one feeds a negative and an out-of-range outputMapping index through DeserializePlans and expects Status::Invalid, so both the generic GetEmitInfo path and ProcessEmitProject are covered. I checked them against the unfixed code too, where both trip the Schema::field DCHECK in a debug build.

[github-actions]

⚠️ GitHub issue #54025 has been automatically assigned in GitHub to PR creator.

[dmitry-chirkov-dremio]

LGTM