libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] buffer overflow/memory corruption in udf_readdir()


From: Rocky Bernstein
Subject: Re: [Libcdio-devel] buffer overflow/memory corruption in udf_readdir()
Date: Tue, 17 Jan 2012 10:43:18 -0500

On Tue, Jan 17, 2012 at 7:25 AM, Pete Batard <address@hidden> wrote:

> On 2012.01.17 02:35, Rocky Bernstein wrote:
>
>> Thanks for the investigation, information and patches. UDF support hasn't
>> had much love for a long while, if ever.
>>
>> UDF support is something that a number of people have asked for, but no
>> one
>> was willing to step up to the plate to work on. For myself, it's just not
>> something I feel like I want to work on even though, yes, I started that
>> code.
>>
>
> Well, while I understand where you're coming from, if UDF support is
> unreliable, that suddenly makes libcdio a lot less interesting for my
> project. I had considered using the ISO/UDF code from 7-zip (which is
> public domain AFAIK) but decided against it mostly because it is C++,
> completely undocumented,


And although I haven't looked in a while, I think the UDF code in kernel
drivers in various OS's like GNU/Linux is also undocumented.



> and also because I prefer reusing (and contributing to) GPL 3.0 projects
> whenever possible.
>

Great!


>
> Sill, all recent Windows installation media are UDF so I need UDF support
> that can at least extract files from.

If that becomes too troublesome, I may have to reconsider.
>
>
>  I'm okay with applying these patches as is on the theory that it moves
>> code
>> forward which is better than keeping it slightly broken.
>>
>
> Since this is a fairly blind workaround, which might cause more harm than
> good (it may break file access --only directory content listing was tested
> so far), I'd rather not have it applied.


Oh, I forgot to ask -- are we sure this is a bug in libcdio? It is possible
that it was valid at the time it was written for an earlier UDF standard.

A while back there was a UDF checker I think it was available from Sony
that dumped out UDF information and said whether something was valid UDF.
I'd be interested in knowing if what you are testing passes a UDF checker.
(A google search on UDF checkers seems to indicate there are a number
available for MS Windows).


Once I'm done experimenting with UDF file extraction, I'll see if I can
> provide something better...
>
>
>  We have crappy code which is
>> only good enough to lure someone into deciding to investigate some aspect
>> that they need or are interested in; and then they rewrite it.
>>
>
> Well, I didn't want to comment, but yeah, some aspects of libcdio looked a
> bit disputable to me (especially that reuse of udf_dirent_t).
>
> As long as I use libcdio, I'll try to feed patches back to improve it --at
> least for the areas that I'm familiar enough.
>

Thanks.


>
> Regards,
>
> /Pete
>
> PS: Thanks for applying the previous patches
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]