Menu
▾
▴
libexif-devel
|
From: Niek B. <ni...@go...> - 2008-09-25 10:20:30
Attachments:
exif.patch
|
Hi developers, Please find a patch attached to this mail that solves a couple of memory-corruption issues, and a couple of 64-bit mode options. The "unsigned int" -> "size_t" type changes are 64-bit fixes; when not using these, one gets offsets in the > 2^31 range at times. The changes to exif-data.c prevent reading from e->data when e->data is NULL, and to prevent calling exif_data_save_data_entry if ifd->entries[j] is NULL. An additional set of changes within the maker-note files are to prevent crashing on sizes > 64kb; It seems that the maker-notes, at times, return sizes that are huge (as in: way beyond 2^31 bytes). According to the documentation, though, the full size of the EXIF data should fit within a JPEG section, thus intrinsically limiting it to 64 kb. I.e.: any s that is > 64 kb indicates a problem within the data. Regards, Niek Bergboer Google Switzerland GmbH Identifikationsnummer: CH-020.4.028.116-1 |
|
From: Marcus M. <ma...@je...> - 2008-09-26 13:19:03
|
On Thu, Sep 25, 2008 at 12:20:06PM +0200, Niek Bergboer wrote: > Hi developers, > > Please find a patch attached to this mail that solves a couple of > memory-corruption issues, and a couple of 64-bit mode options. > > The "unsigned int" -> "size_t" type changes are 64-bit fixes; when not > using these, one gets offsets in the > 2^31 range at times. > > The changes to exif-data.c prevent reading from e->data when e->data > is NULL, and to prevent calling exif_data_save_data_entry if > ifd->entries[j] is NULL. > > An additional set of changes within the maker-note files are to > prevent crashing on sizes > 64kb; It seems that the maker-notes, at > times, return sizes that are huge (as in: way beyond 2^31 bytes). > According to the documentation, though, the full size of the EXIF data > should fit within a JPEG section, thus intrinsically limiting it to 64 > kb. I.e.: any s that is > 64 kb indicates a problem within the data. Is this diff the right way round? It seems you diffed new -> old instead of old -> new Also please use diff -u Ciao, Marcus |
|
From: Niek B. <ni...@go...> - 2008-09-26 13:55:22
Attachments:
exif.patch
|
Hi Marcus, Sure thing. Here is the new version of the patch. Regards, Niek Bergboer Google Switzerland GmbH Identifikationsnummer: CH-020.4.028.116-1 On Fri, Sep 26, 2008 at 3:18 PM, Marcus Meissner <ma...@je...> wrote: > On Thu, Sep 25, 2008 at 12:20:06PM +0200, Niek Bergboer wrote: >> Hi developers, >> >> Please find a patch attached to this mail that solves a couple of >> memory-corruption issues, and a couple of 64-bit mode options. >> >> The "unsigned int" -> "size_t" type changes are 64-bit fixes; when not >> using these, one gets offsets in the > 2^31 range at times. >> >> The changes to exif-data.c prevent reading from e->data when e->data >> is NULL, and to prevent calling exif_data_save_data_entry if >> ifd->entries[j] is NULL. >> >> An additional set of changes within the maker-note files are to >> prevent crashing on sizes > 64kb; It seems that the maker-notes, at >> times, return sizes that are huge (as in: way beyond 2^31 bytes). >> According to the documentation, though, the full size of the EXIF data >> should fit within a JPEG section, thus intrinsically limiting it to 64 >> kb. I.e.: any s that is > 64 kb indicates a problem within the data. > > Is this diff the right way round? It seems you diffed new -> old > instead of old -> new > > Also please use diff -u > > Ciao, Marcus > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > libexif-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libexif-devel > |
|
From: Marcus M. <ma...@je...> - 2008-10-02 06:17:14
|
On Fri, Sep 26, 2008 at 03:54:59PM +0200, Niek Bergboer wrote: > Hi Marcus, > > Sure thing. Here is the new version of the patch. I have applied it as-is, but changed // to regular C comments before to be consistent with the rest of the codebase. Thanks! Ciao, Marcus |
|
From: Dan F. <da...@co...> - 2008-09-25 17:31:52
|
On Thu, Sep 25, 2008 at 12:20:06PM +0200, Niek Bergboer wrote: > Please find a patch attached to this mail that solves a couple of > memory-corruption issues, and a couple of 64-bit mode options. Would you mind resending the patch in unified diff format (-u)? It's more reliable to apply and to review that way. >>> Dan -- http://www.MoveAnnouncer.com The web change of address service Let webmasters know that your web site has moved |
|
From: Jan P. <pa...@pi...> - 2008-10-05 08:22:14
|
> On Thu, Sep 25, 2008 at 12:20:06PM +0200, Niek Bergboer wrote: >> Please find a patch attached to this mail that solves a couple of >> memory-corruption issues, and a couple of 64-bit mode options. > > Would you mind resending the patch in unified diff format (-u)? It's > more reliable to apply and to review that way. > >>>> Dan Dan, It has been resent and then applied by Marcus. I have done few changes since then. I don't know why, but I didn't receive any CVS mails for Marcus' and my changes. Did anybody receive them? -- Jan |
|
From: Marcus M. <ma...@je...> - 2008-10-05 08:29:08
|
On Sun, Oct 05, 2008 at 09:54:30AM +0200, Jan Patera wrote: > > On Thu, Sep 25, 2008 at 12:20:06PM +0200, Niek Bergboer wrote: > >> Please find a patch attached to this mail that solves a couple of > >> memory-corruption issues, and a couple of 64-bit mode options. > > > > Would you mind resending the patch in unified diff format (-u)? It's > > more reliable to apply and to review that way. > > > >>>> Dan > > Dan, It has been resent and then applied by Marcus. I have done few changes > since then. I don't know why, but I didn't receive any CVS > mails for Marcus' and my changes. Did anybody receive them? I got some python errors on commit. I think the CVS move might have broken the mail script :/ Ciao, Marcus |
|
From: Jan P. <pa...@pi...> - 2008-10-05 08:26:27
|
Niek, > The "unsigned int" -> "size_t" type changes are 64-bit fixes; when not > using these, one gets offsets in the > 2^31 range at times. ... > An additional set of changes within the maker-note files are to > prevent crashing on sizes > 64kb; It seems that the maker-notes, at > times, return sizes that are huge (as in: way beyond 2^31 bytes). Doesn't sound possible, unless there is a bug somewhere or the JPEG file is corrupted. Can you please send me some JPEG file where you get sizes over 2^31? Thanks. -- Jan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X