Recherche avancée

Sur d’autres sites (9437)

• avfilter/vf_alphamerge : Fix double-free of AVFilterFormats on error

  7 août 2020, par Andreas Rheinhardt

  avfilter/vf_alphamerge : Fix double-free of AVFilterFormats on error
  The query_formats function of the alphamerge filter tries to allocate
  
  two lists of formats which on success are attached to more permanent
  
  objects (AVFilterLinks) for storage afterwards. If attaching a list
  
  to an AVFilterLink succeeds, the link becomes one of the owners of
  
  the list. Yet if attaching a list to one of its links succeeds and
  
  an error happens lateron, both lists were manually freed, which is wrong
  
  if the list is already owned by one or more links ; these links' pointers
  
  to their lists will become dangling and there will be a double-free/use-
  
  after-free when these links are cleaned up automatically.
  This commit fixes this by removing the custom freeing code ; this will
  
  temporarily add a leaking codepath (if attaching a list not already
  
  owned by a link to a link fails, the list will leak), but this will
  
  be fixed soon by making sure that an AVFilterFormats without owner will
  
  be automatically freed when attaching it to an AVFilterLink fails.
  
  At most one list leaks because as of this commit a new list is only
  
  allocated after the old list has been successfully attached to a link.
  Reviewed-by : Nicolas George <george@nsup.org>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavfilter/vf_alphamerge.c

• avfilter/formats : Fix double frees and memleaks on error

  7 août 2020, par Andreas Rheinhardt

  avfilter/formats : Fix double frees and memleaks on error
  The formats API deals with lists of channel layouts, sample rates,
  
  pixel formats and sample formats. These lists are refcounted in a way in
  
  which the list structure itself contains pointers to all of its owners.
  
  Furthermore, it is possible for a list to be not owned by anyone yet ;
  
  this status is temporary until the list has been attached to an owner.
  
  Adding an owner to a list involves reallocating the list's list of
  
  owners and can therefore fail.
  In order to reduce the amount of checks and cleanup code for the users
  
  of this API, the API is supposed to be lenient when faced with input
  
  lists that are NULL and it is supposed to clean up if adding an owner
  
  to a list fails, so that a simple use case like
  list = ff_make_format_list(foo_fmts) ;
  
  if ((ret = ff_formats_ref(list, &ctx->inputs[0]->out_formats)) < 0)
  
      return ret ;
  needn't check whether list could be successfully allocated
  
  (ff_formats_ref() return AVERROR(ENOMEM) if it couldn't) and it also
  
  needn't free list if ff_formats_ref() couldn't add an owner for it.
  But the cleaning up after itself was broken. The root cause was that
  
  the refcount was decremented during unreferencing whether or not the
  
  element to be unreferenced was actually an owner of the list or not.
  
  This means that if the above sample code is continued by
  if ((ret = ff_formats_ref(list, &ctx->inputs[1]->out_formats)) < 0)
  
      return ret ;
  and that if an error happens at the second ff_formats_ref() call, the
  
  automatic cleaning of list will decrement the refcount from 1 (the sole
  
  owner of list at this moment is ctx->input[0]->out_formats) to 0 and so
  
  the list will be freed ; yet ctx->input[0]->out_formats still points to
  
  the list and this will lead to a double free/use-after-free when
  
  ctx->input[0] is freed later.
  Presumably in order to work around such an issue, commit
  
  93afb338a405eac0f9e7b092bc26603378bfcca6 restricted unreferencing to
  
  lists with owners. This does not solve the root cause (the above example
  
  is not fixed by this) at all, but it solves some crashs.
  This commit fixes the API : The list's refcount is only decremented if
  
  an owner is removed from the list of owners and not if the
  
  unref-function is called with a pointer that is not among the owners of
  
  the list. Furtermore, the requirement for the list to have owners is
  
  dropped.
  This implies that if the first call to ff_formats_ref() in the above
  
  example fails, the refcount which is initially zero during unreferencing
  
  is not modified, so that the list will be freed automatically in said
  
  call to ff_formats_ref() as every list whose refcount reaches zero is.
  If on the other hand, the second call to ff_formats_ref() is the first
  
  to fail, the refcount would stay at one during the automatic
  
  unreferencing in ff_formats_ref(). The list would later be freed when
  
  its last (and in this case sole) owner (namely
  
  ctx->inputs[0]->out_formats) gets unreferenced.
  The issues described here for ff_formats_ref() also affected the other
  
  functions of this API. E.g. ff_add_format() failed to clean up after
  
  itself if adding an entry to an already existing list failed (the case
  
  of a freshly allocated list was handled specially and this commit also
  
  removes said code). E.g. ff_all_formats() inherited the flaw.
  Reviewed-by : Nicolas George <george@nsup.org>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavfilter/formats.c

• avfilter/af_channelmap : Fix double-free of AVFilterChannelLayouts on error

  7 août 2020, par Andreas Rheinhardt

  avfilter/af_channelmap : Fix double-free of AVFilterChannelLayouts on error
  The query_formats function of the channelmap filter tries to allocate
  
  a list of channel layouts which on success are attached to more permanent
  
  objects (an AVFilterLink) for storage afterwards. If attaching succeeds,
  
  the link becomes one of the common owners (in this case, the only owner)
  
  of the list. Yet if the list has been successfully attached to the link
  
  and an error happens lateron, the list was manually freed, which is wrong,
  
  because it is owned by its link so that the link's pointer to the list will
  
  become dangling and there will be a double-free/use-after-free when the link
  
  is later cleaned up automatically.
  This commit fixes this by removing the custom freeing code ; this will
  
  temporarily add a leaking codepath (if attaching the list fails, the list
  
  will leak), but this will be fixed soon by making sure that an
  
  AVFilterChannelLayouts without owner will be automatically freed when
  
  attaching it to an AVFilterLink fails.
  Reviewed-by : Nicolas George <george@nsup.org>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavfilter/af_channelmap.c