Summary
Schema::parse_str / Schema::parse panics (instead of returning Err) when a schema's alias, type reference, or nested type name is not a valid Avro identifier. Because parse_str is a Result-returning public API, callers cannot guard against this with ?/map_err — the panic unwinds out of the parse call. Parsing attacker-controlled schema JSON is therefore a denial-of-service.
This is the same Name::new(..).unwrap() class that was fixed for Name::parse (the top-level name field) in #496, but three sibling sites in schema/parser.rs were not covered.
Reproduction
use apache_avro::Schema;
fn main() {
// panics: called `Result::unwrap()` on an `Err` value:
// Invalid schema name :. It must match the regex '...'
let _ = Schema::parse_str(r#"{"type":"record","name":"R","aliases":[":"],"fields":[]}"#);
}
Observed (apache-avro from main, also every release 0.17.0–0.21.0):
thread 'main' panicked at avro/src/schema/parser.rs:812:57:
called `Result::unwrap()` on an `Err` value: Error { details: Invalid schema name :. ... }
Affected sites (avro/src/schema/parser.rs, current main)
get_already_seen_schema — Name::new_with_enclosing_namespace(typ, ns).unwrap() on a type string reference.
fix_aliases_namespace — Alias::new(alias).unwrap() on each aliases entry.
get_schema_type_name — Name::new(name).unwrap() on a nested type object name.
All three call name constructors that already return AvroResult (they run validate_schema_name), so the validation error exists — it is just unwrap()-ed into a panic.
Proposed fix
Propagate / gracefully handle the validation error instead of unwrapping:
get_already_seen_schema: an unparyable type name cannot match an already-seen schema → return None (.ok()?).
fix_aliases_namespace: return AvroResult<Aliases> and propagate (? at the 3 call sites) — an invalid alias is a schema error.
get_schema_type_name: fall back to the enclosing name (unwrap_or(name)), matching the existing _ => name arm.
PR with fix + regression test to follow.
Summary
Schema::parse_str/Schema::parsepanics (instead of returningErr) when a schema's alias, type reference, or nested type name is not a valid Avro identifier. Becauseparse_stris aResult-returning public API, callers cannot guard against this with?/map_err— the panic unwinds out of the parse call. Parsing attacker-controlled schema JSON is therefore a denial-of-service.This is the same
Name::new(..).unwrap()class that was fixed forName::parse(the top-levelnamefield) in #496, but three sibling sites inschema/parser.rswere not covered.Reproduction
Observed (apache-avro from
main, also every release 0.17.0–0.21.0):Affected sites (
avro/src/schema/parser.rs, currentmain)get_already_seen_schema—Name::new_with_enclosing_namespace(typ, ns).unwrap()on atypestring reference.fix_aliases_namespace—Alias::new(alias).unwrap()on eachaliasesentry.get_schema_type_name—Name::new(name).unwrap()on a nestedtypeobject name.All three call name constructors that already return
AvroResult(they runvalidate_schema_name), so the validation error exists — it is justunwrap()-ed into a panic.Proposed fix
Propagate / gracefully handle the validation error instead of unwrapping:
get_already_seen_schema: an unparyable type name cannot match an already-seen schema → returnNone(.ok()?).fix_aliases_namespace: returnAvroResult<Aliases>and propagate (?at the 3 call sites) — an invalid alias is a schema error.get_schema_type_name: fall back to the enclosing name (unwrap_or(name)), matching the existing_ => namearm.PR with fix + regression test to follow.