[MPlayer-dev-eng] [PATCH] fix use-after-free in vo_vdpau

[Rinat Ibragimov]

Вторник, 15 октября 2013, 21:05 +02:00 от Reimar Döffinger <Reimar.Doeffinger at gmx.de>:
>On Tue, Oct 15, 2013 at 08:59:48PM +0200, Reimar Döffinger wrote:
>> On Tue, Oct 15, 2013 at 12:46:06PM +0400, Rinat Ibragimov wrote:
>> > 
>> > Вторник, 15 октября 2013, 8:24 +02:00 от Reimar Döffinger < Reimar.Doeffinger at gmx.de >:
>> > > On 14.10.2013, at 22:01, Alexander Strasser < eclipse7 at gmx.net > wrote:
>> > > > Hi,
>> > > > 
>> > > > On 2013-10-14 19:56 +0400, Rinat Ibragimov wrote:
>> > > >> Hi, I've faced use-after-free in vo_vdpau.c. The issue may arise when one switches to
>> > > >> next video in playlist. Here is a patch that should prevent that.
>> > > > 
>> > > >  keeping allocated arrays and associated size fields in sync,
>> > > > seems like a good idea to me. Beware I didn't read the code
>> > > > closely so there might well be more underlying problems.
>> > > 
>> > > Since the pointers are set to NULL I can't see how a use-after-free would happen, a valgrind log would help.
>> > 
>> > It's not exactly use-after-free, more like NULL pointer dereference. Sorry for misleading.
>> 
>> That makes more sense, however your approach isn't quite right IMHO.
>> The sizes are not set to 0 here, because they are not supposed to be
>> used at any point after uninit.
>> What went wrong here is actually that in preinit we end up using
>> those _size variables right before we initialize them (to 0).
>> Which is kind of the reason why I kind of prefer not setting the
>> counts to 0 in uninit, since that should result in such relatively easy
>> to debug crashes (I kind of follow the crashes == next best
>> thing after bug-free philosophy).
>> I never noticed it because I usually use -fixed-vo and rarely
>> play more than one video anyway.
>> I believe it should be fixed in r36467.

Thank you for the fix, now issue is gone.

>
>And I forgot to say: nice project.
>Since we never got anywhere with integrating libva support in
>MPlayer it is great if users will have another option besides
>third-party patches.

Thanks.

>Though with native VPDAU support even in AMD OpenSource drivers
>maybe Intel will change their mind, too, and give up on libva :-)

I don't think Intel will change their mind. They have encoding support which
unlikely to be supported by VDPAU. And with with VA-API they are free
to change it as they wish (and they do a lot). So users with Intel hardware
are stuck with VA-API for an observable future.

---
Rinat