On Sat, Apr 13, 2013 at 9:54 AM, Anton Khirnov <[email protected]> wrote: > > On Sat, 13 Apr 2013 08:21:38 +0200, Reinhard Tartler <[email protected]> > wrote: >> reported by clang-scan analysis >> --- >> libavfilter/af_channelmap.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/libavfilter/af_channelmap.c b/libavfilter/af_channelmap.c >> index da83009..9f4f4d0 100644 >> --- a/libavfilter/af_channelmap.c >> +++ b/libavfilter/af_channelmap.c >> @@ -92,9 +92,13 @@ static char* split(char *message, char delim) { >> >> static int get_channel_idx(char **map, int *ch, char delim, int max_ch) >> { >> - char *next = split(*map, delim); >> + char *next; >> int len; >> int n = 0; >> + >> + if (!*map) >> + return AVERROR(EINVAL); >> + next = split(*map, delim); >> if (!next && delim == '-') >> return AVERROR(EINVAL); >> len = strlen(*map); >> -- >> 1.7.9.5 >> > > TBH I don't see how this could ever happen. > > If mapping is NULL from the beginning, get_channel_idx() doesn't even get > called. It could become NULL as a result of *map = next assignment, but the > only > place where get_channel_idx() is called twice is the MAP_PAIR_INT_INT case, > but there delim == '-', so the > if (!next && delim == '-') > return AVERROR(EINVAL); > check protects us.
It indeed seems to be impossible to create this situation using the built-in channel-map parser. However, and AFAIUI, it is not completely impossible to have an application that constructs its channel map by other means and passes something bogus to cause the situation described at http://fate.libav.org/csa/report-Wg2Pol.html#Path20. Admittedly, I'm not aware of any other consumer of lavfi than avconv, but AFAIUI, the plan was to change that, correct? -- regards, Reinhard _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
