When digging the application, I found this vulnerability in the program,
because when the sws_scale function was called, the application did not
check the validity of the parameters, resulting in an address access
exception vulnerability. So I want to know if this is a problem in FFmpage,
so I sent you an email to confirm it.
On Tue, Mar 17, 2020 at 11:30 AM Andriy Gelman <andriy.gel...@gmail.com>
wrote:
> On Mon, 16. Mar 10:02, Ming Qian wrote:
> > the draining is set when the output port is finished,
> > but it doesn't mean the capture port is finished.
> > especially for decoder, there may be a stream buffer to store several
> > frames.
> > so the decoder still need capture buffer even if the draining is set.
> >
> > Signed-off-by: Ming Qian <ming.q...@nxp.com>
> > ---
> > libavcodec/v4l2_buffers.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
> > index dc1b9eaf24..02f23d954b 100644
> > --- a/libavcodec/v4l2_buffers.c
> > +++ b/libavcodec/v4l2_buffers.c
> > @@ -222,7 +222,7 @@ static void v4l2_free_buffer(void *opaque, uint8_t
> *unused)
> > if (!atomic_load(&s->refcount))
> > sem_post(&s->refsync);
> > } else {
> > - if (s->draining) {
> > + if (s->draining &&
> V4L2_TYPE_IS_OUTPUT(avbuf->context->type)) {
> > /* no need to queue more buffers to the driver */
> > avbuf->status = V4L2BUF_AVAILABLE;
> > }
>
> It makes sense, but did you have some dropped frames without this?
>
> Thanks,
> --
> Andriy
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
