Nayana-Naik73 opened a new issue, #54025:
URL: https://github.com/apache/arrow/issues/54025
### Describe the bug, including details regarding any error messages,
version, and platform.
While reading the Substrait relation conversion I noticed that GetEmitInfo
and ProcessEmitProject in cpp/src/arrow/engine/substrait/relation_internal.cc
take each emit output_mapping value straight from the plan and use it to index
input_schema->field(map_id) (and, for ProjectRel, the project expression
vector) without any range check. Schema::field is only guarded by a DCHECK, so
in release builds a plan with a negative or out-of-range output_mapping index
reads past the end of the field vector, and the ProjectRel path also moves an
out-of-bounds compute::Expression.
This is reachable from DeserializePlan / DeserializePlans on untrusted plan
bytes, for essentially any relation that goes through the emit path (read,
filter, join, fetch, sort, aggregate, set, project). In a debug build it trips
the "Check failed: (i) < (num_fields())" DCHECK in Schema::field.
ProcessExtensionEmit already rejects the same condition with
Status::Invalid("Out of bounds emit index ..."), so I'd expect the other two
emit helpers to do the same.
Minimal trigger: a ReadRel over a 3-column base schema with "common":
{"emit": {"outputMapping": [0, 3]}} (or [-1, 1]).
### Component(s)
C++
--
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]
