[
https://issues.apache.org/jira/browse/AVRO-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ismaël Mejía reassigned AVRO-4305:
----------------------------------
> C: make st_insert() OOM-safe (check avro_new() allocation failure)
> ------------------------------------------------------------------
>
> Key: AVRO-4305
> URL: https://issues.apache.org/jira/browse/AVRO-4305
> Project: Apache Avro
> Issue Type: Improvement
> Components: c
> Reporter: Ismaël Mejía
> Assignee: Ismaël Mejía
> Priority: Major
>
> h2. Summary
> The vendored {{st}} hash table used by the C SDK ({{lang/c/src/st.c}})
> allocates
> table entries via {{avro_new()}} in {{st_insert()}}/{{ADD_DIRECT}} (around
> st.c:260-267) without checking for a NULL return. On allocation failure this
> can
> dereference NULL and crash rather than returning an error, so map decoding
> (and
> any other {{st}} user) is not OOM-safe on that path.
> h2. Context
> Noted during review of AVRO-4293 (bound allocation when decoding
> length-prefixed values and collections). That PR removed the NULL-dereference
> on
> {{avro_raw_array_append}}/{{avro_strdup}} in {{map.c}}, but {{st_insert()}}'s
> internal allocation remains unchecked. Making {{st_insert()}}/{{ADD_DIRECT}}
> handle allocation failure (return an error and leave the table unchanged) is a
> broader change to shared code and was deliberately kept out of that PR's
> scope.
> h2. Proposed approach
> * Make {{st_insert()}} (and the {{ADD_DIRECT}} macro) detect a failed
> {{avro_new()}} and return an error/failure indication, leaving the table
> unchanged.
> * Update callers (e.g. {{avro_generic_map}} in {{map.c}}) to propagate the
> error
> and roll back (element count, key copy) on failure.
> * Audit other {{st}} users for the new failure mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
