Menu
▾
▴
libquicktime-devel — Discussion about development
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
(59) |
Mar
(82) |
Apr
(28) |
May
(31) |
Jun
(52) |
Jul
(6) |
Aug
(10) |
Sep
(3) |
Oct
(13) |
Nov
(8) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(32) |
Feb
(14) |
Mar
|
Apr
(9) |
May
|
Jun
(15) |
Jul
|
Aug
(2) |
Sep
(5) |
Oct
|
Nov
(28) |
Dec
(17) |
| 2004 |
Jan
(16) |
Feb
(8) |
Mar
(8) |
Apr
(9) |
May
(5) |
Jun
(31) |
Jul
(38) |
Aug
(34) |
Sep
(11) |
Oct
(48) |
Nov
(12) |
Dec
(52) |
| 2005 |
Jan
(41) |
Feb
(1) |
Mar
(3) |
Apr
(22) |
May
(100) |
Jun
(77) |
Jul
(42) |
Aug
(103) |
Sep
(10) |
Oct
(6) |
Nov
(44) |
Dec
(21) |
| 2006 |
Jan
(35) |
Feb
(5) |
Mar
(34) |
Apr
(24) |
May
(19) |
Jun
(45) |
Jul
(64) |
Aug
(32) |
Sep
(6) |
Oct
(23) |
Nov
(23) |
Dec
(65) |
| 2007 |
Jan
(9) |
Feb
(37) |
Mar
(51) |
Apr
(35) |
May
(11) |
Jun
(11) |
Jul
(2) |
Aug
(10) |
Sep
(6) |
Oct
(66) |
Nov
(30) |
Dec
(10) |
| 2008 |
Jan
(53) |
Feb
(38) |
Mar
(22) |
Apr
(5) |
May
(74) |
Jun
|
Jul
(11) |
Aug
(20) |
Sep
(37) |
Oct
(44) |
Nov
(10) |
Dec
(25) |
| 2009 |
Jan
(7) |
Feb
|
Mar
(25) |
Apr
(26) |
May
(7) |
Jun
(29) |
Jul
(3) |
Aug
(6) |
Sep
(22) |
Oct
(11) |
Nov
(4) |
Dec
(1) |
| 2010 |
Jan
(12) |
Feb
(22) |
Mar
(23) |
Apr
(19) |
May
(21) |
Jun
(10) |
Jul
(11) |
Aug
|
Sep
(1) |
Oct
(5) |
Nov
(4) |
Dec
(15) |
| 2011 |
Jan
(18) |
Feb
(16) |
Mar
(15) |
Apr
(4) |
May
(27) |
Jun
(3) |
Jul
(2) |
Aug
(6) |
Sep
(1) |
Oct
(3) |
Nov
(9) |
Dec
(5) |
| 2012 |
Jan
(5) |
Feb
(16) |
Mar
(13) |
Apr
|
May
(16) |
Jun
(32) |
Jul
|
Aug
(16) |
Sep
(15) |
Oct
(1) |
Nov
(27) |
Dec
(2) |
| 2013 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
(9) |
May
(9) |
Jun
(4) |
Jul
|
Aug
(5) |
Sep
(4) |
Oct
(14) |
Nov
(11) |
Dec
(3) |
| 2014 |
Jan
|
Feb
|
Mar
(11) |
Apr
(15) |
May
(5) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(3) |
Oct
(9) |
Nov
(1) |
Dec
|
| 2015 |
Jan
(1) |
Feb
(1) |
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(7) |
Jul
(2) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jean-Yves H. <jy...@cs...> - 2020-05-26 16:13:28
|
Hi， Thank you very much! I don’t know what I didn’t think of that. I kept looking for stuff in the various Library folders, wondering what could have been removed or disable by a system update, and it never occurred to me that a recent MacPorts update of ffmpeg might be the culprit. It has been a while since I last had to write new code using libquicktime (just rebuilt old demo projects of my computer vision library to make sure that were still running) and I guess I have forgotten the little I ever knew about it. I should take that as a reason to update my old projects to use straight ffmpeg instead. Best, Jean-Yves Hervé. On 26 May 2020 at 04:31:47 , Burkhard Plaum, (bur...@ig...) wrote: Hi, for avc1 decoding you need ffmpeg, but probably an older version since the libquicktime code wasn't updated for a while. There were some fundamental changes in the ffmpeg API since then. Maybe someone wants to upgrade the libacodec frontend. Right now I don't have time to work in libquicktime (and I stopped using it personally a while ago already). Cheers Burkhard ________________________________________ From: Jean-Yves Hervé <jy...@cs...> Sent: Thursday, May 21, 2020 9:42:11 PM To: lib...@li... Subject: [Libquicktime-devel] Could not find video Decoder Greetings, I assume that this list is more or less dead, but just in case it’s only dormant… :-) Sometime in the past 12 months, my projects that were using libquicktime all started displaying the "Could not find video Decoder” message whenever I attempt to play a movie file. This happens for very classical codecs like avc1 or dmb1, all types that I managed to play just fine only a while back (and of course still play in VLC), with no change in my code. I get that message both on mac OS (10.14 Mojave) and Ubuntu Linux (18 through 20). I would assume that I forgot to install something on both platform the last time I reinstalled both systems. On the Mac, I installed libquicktime-dev through MacPorts. Also installing x264 made no change. A pointer to the proper software to install to get my old libquicktime projects to run again would be much appreciated. Otherwise what did you all move too? Straight ffmpeg? Best Regards, jyh. -- ==================================================================== jean-yves hervé /\ 3D Group for Interactive Visualization \/ Mail --> jy...@cs... Dept. of Computer Science and Statistics /\ University of Rhode Island \/ Tel. --> (401) 874-2701 Kingston, RI 02881-0816 /\ Fax. --> (401) 874-4617 USA \/ ==================================================================== _______________________________________________ Libquicktime-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libquicktime-devel -- ==================================================================== jean-yves hervé /\ 3D Group for Interactive Visualization \/ Mail --> jy...@cs... Dept. of Computer Science and Statistics /\ University of Rhode Island \/ Tel. --> (401) 874-2701 Kingston, RI 02881-0816 /\ Fax. --> (401) 874-4617 USA \/ ==================================================================== |
|
From: Plaum, B. <bur...@ig...> - 2020-05-26 08:56:51
|
Hi, for avc1 decoding you need ffmpeg, but probably an older version since the libquicktime code wasn't updated for a while. There were some fundamental changes in the ffmpeg API since then. Maybe someone wants to upgrade the libacodec frontend. Right now I don't have time to work in libquicktime (and I stopped using it personally a while ago already). Cheers Burkhard ________________________________________ From: Jean-Yves Hervé <jy...@cs...> Sent: Thursday, May 21, 2020 9:42:11 PM To: lib...@li... Subject: [Libquicktime-devel] Could not find video Decoder Greetings, I assume that this list is more or less dead, but just in case it’s only dormant… :-) Sometime in the past 12 months, my projects that were using libquicktime all started displaying the "Could not find video Decoder” message whenever I attempt to play a movie file. This happens for very classical codecs like avc1 or dmb1, all types that I managed to play just fine only a while back (and of course still play in VLC), with no change in my code. I get that message both on mac OS (10.14 Mojave) and Ubuntu Linux (18 through 20). I would assume that I forgot to install something on both platform the last time I reinstalled both systems. On the Mac, I installed libquicktime-dev through MacPorts. Also installing x264 made no change. A pointer to the proper software to install to get my old libquicktime projects to run again would be much appreciated. Otherwise what did you all move too? Straight ffmpeg? Best Regards, jyh. -- ==================================================================== jean-yves hervé /\ 3D Group for Interactive Visualization \/ Mail --> jy...@cs... Dept. of Computer Science and Statistics /\ University of Rhode Island \/ Tel. --> (401) 874-2701 Kingston, RI 02881-0816 /\ Fax. --> (401) 874-4617 USA \/ ==================================================================== |
|
From: Jean-Yves H. <jy...@cs...> - 2020-05-21 19:58:10
|
Greetings, I assume that this list is more or less dead, but just in case it’s only dormant… :-) Sometime in the past 12 months, my projects that were using libquicktime all started displaying the "Could not find video Decoder” message whenever I attempt to play a movie file. This happens for very classical codecs like avc1 or dmb1, all types that I managed to play just fine only a while back (and of course still play in VLC), with no change in my code. I get that message both on mac OS (10.14 Mojave) and Ubuntu Linux (18 through 20). I would assume that I forgot to install something on both platform the last time I reinstalled both systems. On the Mac, I installed libquicktime-dev through MacPorts. Also installing x264 made no change. A pointer to the proper software to install to get my old libquicktime projects to run again would be much appreciated. Otherwise what did you all move too? Straight ffmpeg? Best Regards, jyh. -- ==================================================================== jean-yves hervé /\ 3D Group for Interactive Visualization \/ Mail --> jy...@cs... Dept. of Computer Science and Statistics /\ University of Rhode Island \/ Tel. --> (401) 874-2701 Kingston, RI 02881-0816 /\ Fax. --> (401) 874-4617 USA \/ ==================================================================== |
|
From: Sérgio B. <se...@se...> - 2018-02-06 15:54:15
|
OK , with acknowledgement of the mailing list nothing particular private was write . On Fri, 2018-02-02 at 10:52 +0100, Burkhard Plaum wrote: > Hi, > > Am 01.02.2018 um 18:05 schrieb Sérgio Basto: > > On Tue, 2018-01-23 at 10:29 +0100, Burkhard Plaum wrote: > > > Am 23.01.2018 um 01:18 schrieb Sérgio Basto: > > > > > > > > > > > yes , I need more permissions at least to add git ... > > > > > > Ok you should be admin now. > > > > > > Hello > > > > I saw your commit today ... > > > > I have done the migration to git , and all went well > > Yea I saw that, thanks a lot. > > > Currently libquicktime doesn't compile with ffmpeg 3.5 (not yet > > released ) but compiles with ffmpeg 3.4.1 > > > > I made one branch if I got something to fix , I will commit there , > > but > > may I merge to master ? do you want review it before ? etc > > If you can make a patch, I can take a look at it. > We never had different branches for libquicktime, because of slow > development and > few active developers, so I'd not be against using just the master > branch exclusively. > But if people feel more save using a development branch it's also ok. > > In the past we always supported a wide range of versions via #ifdefs. > But I think the ffmpeg > APIs got more stable nowadays. There are certainly parts of the > libquicktime code which > would deserve some cleanups. > > Also, please use libquicktime-devel for communication. It's a quiet > list but > normally people are listening. Maybe there are also opinions about > which ffmpeg > versions to support. My maintain could be on autotools and fix warning or deprecated functions ... , if and when I got some time , I may commit in code_maintain branch of libquicktime , to you review before merge to master. Thanks -- Sérgio M. B. |
|
From: Burkhard P. <bur...@ig...> - 2018-01-22 17:10:06
|
Hi, Am 22.01.2018 um 17:50 schrieb Sérgio Basto: [...] > But have we any replacement for libquicktime and to read mov videos ? For decoding I personally use my gmerlin-avdecoder library. It's not well known. But for me it has the advantage, that I can add all crazy features I want :) For *encoding* video files, I use libavformat and libavcodec. I guess that libavformat is also good at decoding nowadays, but when I started my projects (around 2001/2002) it certainly wasn't. > If you give access to the project I can do: git push -u origin master > to sf.net which is the way that I see that will give us less work . Give me your souceforge user ID (can also be off-list) and I'll add you. Burkhard |
|
From: Sérgio B. <se...@se...> - 2018-01-22 16:50:51
|
On Mon, 2018-01-22 at 17:25 +0100, Burkhard Plaum wrote: > Hi, > > I'm aware that sourceforge closed CVS. I didn't make the transition > because the > project activity in the past months is close to zero and I'm busy > with other things. > > Of course I support the idea to move to git. The question is if it > should be on sourceforge > or github? Are there any opinions about that? > I'd be ok with any solution (including moving the whole project away > from SF) as long as > a volunteer does it :) > > I'm not sure about the user base of libquicktime. I stopped using it > myself several years ago. But have we any replacement for libquicktime and to read mov videos ? If you give access to the project I can do: git push -u origin master to sf.net which is the way that I see that will give us less work . Working with git give us very versatility , see my scripts [1]1 https://pkgs.rpmfusion.org/cgit/free/libquicktime.git/tree/update_libqu icktime.sh https://pkgs.rpmfusion.org/cgit/free/libquicktime.git/tree/converttogit .sh > Burkhard > > > Am 21.01.2018 um 23:07 schrieb Sérgio Basto: > > Hi , > > As you may know sourceforge close cvs , I already talked with other > > projects like ufraw , dvdstyler to migrate to git , you just need > > do : > > > > > > cvs -d:pserver:ano...@li...:/cvsroot/ > > libquicktime login > > cvs -z3 -d:pserver:ano...@li...:/cvsr > > oot/libquicktime co -P libquicktime > > cd libquicktime > > git cvsimport -v > > > > In github.com press + and new repository, choose repository name: > > libquicktime > > without "Initialize this repository with a README" . > > and run: > > > > git remote add origin gi...@gi...:sergiomb2/libquicktime.git > > git push -u origin master > > > > and I got this : > > https://github.com/sergiomb2/libquicktime/commits/master > > > > > > with this method you preserve all commit history . > > > > Best regards and Thanks, > > > > -- Sérgio M. B. |
|
From: Burkhard P. <bur...@ig...> - 2018-01-22 16:44:09
|
Hi, I'm aware that sourceforge closed CVS. I didn't make the transition because the project activity in the past months is close to zero and I'm busy with other things. Of course I support the idea to move to git. The question is if it should be on sourceforge or github? Are there any opinions about that? I'd be ok with any solution (including moving the whole project away from SF) as long as a volunteer does it :) I'm not sure about the user base of libquicktime. I stopped using it myself several years ago. Burkhard Am 21.01.2018 um 23:07 schrieb Sérgio Basto: > Hi , > As you may know sourceforge close cvs , I already talked with other > projects like ufraw , dvdstyler to migrate to git , you just need do : > > > cvs -d:pserver:ano...@li...:/cvsroot/libquicktime login > cvs -z3 -d:pserver:ano...@li...:/cvsroot/libquicktime co -P libquicktime > cd libquicktime > git cvsimport -v > > In github.com press + and new repository, choose repository name: libquicktime > without "Initialize this repository with a README" . > and run: > > git remote add origin gi...@gi...:sergiomb2/libquicktime.git > git push -u origin master > > and I got this : > https://github.com/sergiomb2/libquicktime/commits/master > > > with this method you preserve all commit history . > > Best regards and Thanks, > -- Dr. Burkhard Plaum Institut für Grenzflächenverfahrenstechnik und Plasmatechnologie Universität Stuttgart Pfaffenwaldring 31, 70569 Stuttgart Tel.: +49 711 / 685-62174, Fax.: +49 711 / 685-63102 |
|
From: Sérgio B. <se...@se...> - 2018-01-21 22:31:11
|
Hi , As you may know sourceforge close cvs , I already talked with other projects like ufraw , dvdstyler to migrate to git , you just need do : cvs -d:pserver:ano...@li...:/cvsroot/libquicktime login cvs -z3 -d:pserver:ano...@li...:/cvsroot/libquicktime co -P libquicktime cd libquicktime git cvsimport -v In github.com press + and new repository, choose repository name: libquicktime without "Initialize this repository with a README" . and run: git remote add origin gi...@gi...:sergiomb2/libquicktime.git git push -u origin master and I got this : https://github.com/sergiomb2/libquicktime/commits/master with this method you preserve all commit history . Best regards and Thanks, -- Sérgio M. B. |
|
From: Erik J. <eri...@gm...> - 2017-09-25 17:28:02
|
Hi, On Mon, Sep 25, 2017 at 11:38 AM, Burkhard Plaum <bur...@ig...> wrote: > Any volunteer wants to make a patch? Patch attached. // Erik |
|
From: Burkhard P. <bur...@ig...> - 2017-09-25 09:58:24
|
Hi, Am 25.09.2017 um 11:09 schrieb Phil Barrett via Libquicktime-devel: > On Sun, 24 Sep 2017 14:46:04 +0100, Erik Johansson <eri...@gm...> wrote: > >> I have no further info on this other than sample files, but seeing how >> the mac timestamps are nearing the end of the 32-bit range, it seems >> plausible they've expanded them to 64-bits. > > See https://www.adobe.com/content/dam/Adobe/en/devnet/flv/pdfs/video_file_format_spec_v10.pdf for some documentation that agrees with you. On pages 24 and 25 it says for version == 1, creationtime, modification time and duration become 64 bits in the mdhd "box". This makes it 12 bytes larger (44 instead of 32). ffmpeg also has code to handle these (libavformat/mov.c, mov_read_mdhd()). I guess that's enough "documentation" :) Any volunteer wants to make a patch? Burkhard |
|
From: Phil B. <ph...@fi...> - 2017-09-25 09:24:38
|
On Sun, 24 Sep 2017 14:46:04 +0100, Erik Johansson <eri...@gm...> wrote: > I have no further info on this other than sample files, but seeing how > the mac timestamps are nearing the end of the 32-bit range, it seems > plausible they've expanded them to 64-bits. See https://www.adobe.com/content/dam/Adobe/en/devnet/flv/pdfs/video_file_format_spec_v10.pdf for some documentation that agrees with you. Phil -- Phil Barrett FilmLight |
|
From: Erik J. <eri...@gm...> - 2017-09-24 13:46:32
|
Hi,
I captured a screen recording in iOS 11, which created a file that
could not be read using libquicktime. The issue is that the mdhd-atom
is 44 bytes rather than 32.
It appears from looking at the data that the two timestamps and the
duration has changed from 32-bit to 64-bit, and that this change is
indicated by the value 0x01 in the first byte rather than 0x00.
Sample mdhd atom:
0x7fff5fbab930: 01 00 00 00 00 00 00 00 d5 ed 2e fa 00 00 00 00
........??.?....
0x7fff5fbab940: d5 ed 2e fa 00 00 75 30 00 00 00 00 00 48 c9 85
??.?..u0.....H?.
0x7fff5fbab950: 55 c4 00 00
Translating this into code from mdhd.c, with new data appended as comments:
void quicktime_read_mdhd(quicktime_t *file, quicktime_mdhd_t *mdhd)
{
mdhd->version = quicktime_read_char(file);
mdhd->flags = quicktime_read_int24(file);
// 0x00 00 00 00
mdhd->creation_time = quicktime_read_int32(file);
// 0x00 00 00 00
mdhd->modification_time = quicktime_read_int32(file);
mdhd->time_scale = quicktime_read_int32(file);
// 0x00 00 00 00
mdhd->duration = quicktime_read_int32(file);
mdhd->language = quicktime_read_int16(file);
mdhd->quality = quicktime_read_int16(file);
}
I have no further info on this other than sample files, but seeing how
the mac timestamps are nearing the end of the 32-bit range, it seems
plausible they've expanded them to 64-bits.
No patch as this is all anecdotal at this point.
Thanks,
// Erik
|
|
From: Burkhard P. <bur...@ig...> - 2017-07-18 14:16:58
|
Hi, Am 18.07.2017 um 15:22 schrieb Erik Johansson: > Hi, > > I found that there is a bug reading udta atoms when an invalid > @cmt-atom occurs after a valid @cmt-atom has been read, in a context > where have_ilst is set. > > The memory allocated for the valid @cmt-atom will be free'ed, but > udta->comment_len and udta->comment will remain set, causing an > invalid call to free() for udta->comment on close. > > Some DJI-drones creates .m4v-files affected by this problem. > > Patch attached. Applied > Thanks, > Erik Burkhard |
|
From: Erik J. <eri...@gm...> - 2017-07-18 13:22:47
|
Hi, I found that there is a bug reading udta atoms when an invalid @cmt-atom occurs after a valid @cmt-atom has been read, in a context where have_ilst is set. The memory allocated for the valid @cmt-atom will be free'ed, but udta->comment_len and udta->comment will remain set, causing an invalid call to free() for udta->comment on close. Some DJI-drones creates .m4v-files affected by this problem. Patch attached. Thanks, Erik |
|
From: Burkhard P. <bur...@ig...> - 2017-06-23 14:19:05
|
Hi, maybe I use the opportunity of a slightly increased noise-level for a general status update: I personally stopped using libquicktime several years ago and my motivation for active development is near zero. On the other hand, I know that libquicktime is too precious to abandon (it made me learn a LOT of things in many areas). So I will try to fix bugs and apply patches depending on your input. This means you should not expect an official realease anytime soon as long as noone else is ready and able to jump in. But the current CVS can be considered stable enough to be packaged. An official tarball wouldn't be better. Burkhard |
|
From: Burkhard P. <bur...@ig...> - 2017-06-23 14:09:14
|
Hi, I committed some (mostly trivial) updates to CVS. The following CVE's are fixed and/or no longer reproducible: CVE-2017-9122 CVE-2017-9123 CVE-2017-9124 CVE-2017-9125 CVE-2017-9126 CVE-2017-9127 CVE-2017-9128 I was a bit surprised that one simple sanity check fixes a whole bunch of files. So it could be, that the problems are still there, but better hidden since the critical code isn't executed anymore with the sample files I got. If someone encounters more crashes, feel free to report them. Burkhard |
|
From: Burkhard P. <bur...@ig...> - 2017-06-23 13:42:44
|
Hi, thanks for the report. I committed a trivial fix, which can easily be backported to older versions also. It belongs to the end of the function quicktime_atom_read_header(). Index: src/atom.c =================================================================== RCS file: /cvsroot/libquicktime/libquicktime/src/atom.c,v retrieving revision 1.24 diff -r1.24 atom.c 133a134,136 > /* Avoid broken files */ > if(atom->end > file->total_length) > result = 1; It fixes allocation-failed-in_quicktime_read_ftyp and allocation-failed-in_quicktime_read_info. The patch doesn't hurt in any case, but there might still be files, which make lqt crash. I'll look for the other reported problems (CVE-2017-9122 - CVE-2017-9128) ASAP. Burkhard |
|
From: haojun h. <hao...@gm...> - 2017-06-11 15:54:24
|
On libquicktime 1.2.4, a crafted file revealed an allocation failed in the
function quicktime_read_info .
#qtinfo $POC
==2892==ERROR: AddressSanitizer failed to allocate 0x6c6d769000
(465692954624) bytes of LargeMmapAllocator (error code: 12)
==2892==Process memory map follows:
0x000000400000-0x0000008b5000
/home/test/Downloads/libquicktime-afl-build/bin/qtinfo
0x000000ab5000-0x000000ab6000
/home/test/Downloads/libquicktime-afl-build/bin/qtinfo
0x000000ab6000-0x000000ad2000
/home/test/Downloads/libquicktime-afl-build/bin/qtinfo
0x000000ad2000-0x000001739000
0x00007fff7000-0x00008fff7000
0x00008fff7000-0x02008fff7000
0x02008fff7000-0x10007fff8000
0x600000000000-0x602000000000
0x602000000000-0x602000010000
0x602000010000-0x602e00000000
0x602e00000000-0x602e00010000
0x602e00010000-0x604000000000
0x604000000000-0x604000010000
0x604000010000-0x604e00000000
0x604e00000000-0x604e00010000
0x604e00010000-0x606000000000
0x606000000000-0x606000010000
0x606000010000-0x606e00000000
0x606e00000000-0x606e00010000
0x606e00010000-0x608000000000
0x608000000000-0x608000010000
0x608000010000-0x608e00000000
0x608e00000000-0x608e00010000
0x608e00010000-0x616000000000
0x616000000000-0x616000010000
0x616000010000-0x616e00000000
0x616e00000000-0x616e00010000
0x616e00010000-0x624000000000
0x624000000000-0x624000010000
0x624000010000-0x624e00000000
0x624e00000000-0x624e00010000
0x624e00010000-0x626000000000
0x626000000000-0x626000010000
0x626000010000-0x626e00000000
0x626e00000000-0x626e00010000
0x626e00010000-0x640000000000
0x640000000000-0x640000003000
0x7f9b80b00000-0x7f9b80c00000
0x7f9b80d00000-0x7f9b80e00000
0x7f9b80f00000-0x7f9b81000000
0x7f9b81100000-0x7f9b81200000
0x7f9b8125e000-0x7f9b835b0000
0x7f9b835b0000-0x7f9b83766000 /usr/lib64/libc-2.17.so
0x7f9b83766000-0x7f9b83966000 /usr/lib64/libc-2.17.so
0x7f9b83966000-0x7f9b8396a000 /usr/lib64/libc-2.17.so
0x7f9b8396a000-0x7f9b8396c000 /usr/lib64/libc-2.17.so
0x7f9b8396c000-0x7f9b83971000
0x7f9b83971000-0x7f9b83986000 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
0x7f9b83986000-0x7f9b83b85000 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
0x7f9b83b85000-0x7f9b83b86000 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
0x7f9b83b86000-0x7f9b83b87000 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
0x7f9b83b87000-0x7f9b83b8e000 /usr/lib64/librt-2.17.so
0x7f9b83b8e000-0x7f9b83d8d000 /usr/lib64/librt-2.17.so
0x7f9b83d8d000-0x7f9b83d8e000 /usr/lib64/librt-2.17.so
0x7f9b83d8e000-0x7f9b83d8f000 /usr/lib64/librt-2.17.so
0x7f9b83d8f000-0x7f9b83da6000 /usr/lib64/libpthread-2.17.so
0x7f9b83da6000-0x7f9b83fa5000 /usr/lib64/libpthread-2.17.so
0x7f9b83fa5000-0x7f9b83fa6000 /usr/lib64/libpthread-2.17.so
0x7f9b83fa6000-0x7f9b83fa7000 /usr/lib64/libpthread-2.17.so
0x7f9b83fa7000-0x7f9b83fab000
0x7f9b83fab000-0x7f9b83fad000 /usr/lib64/libdl-2.17.so
0x7f9b83fad000-0x7f9b841ad000 /usr/lib64/libdl-2.17.so
0x7f9b841ad000-0x7f9b841ae000 /usr/lib64/libdl-2.17.so
0x7f9b841ae000-0x7f9b841af000 /usr/lib64/libdl-2.17.so
0x7f9b841af000-0x7f9b841c4000 /usr/lib64/libz.so.1.2.7
0x7f9b841c4000-0x7f9b843c3000 /usr/lib64/libz.so.1.2.7
0x7f9b843c3000-0x7f9b843c4000 /usr/lib64/libz.so.1.2.7
0x7f9b843c4000-0x7f9b843c5000 /usr/lib64/libz.so.1.2.7
0x7f9b843c5000-0x7f9b844c5000 /usr/lib64/libm-2.17.so
0x7f9b844c5000-0x7f9b846c5000 /usr/lib64/libm-2.17.so
0x7f9b846c5000-0x7f9b846c6000 /usr/lib64/libm-2.17.so
0x7f9b846c6000-0x7f9b846c7000 /usr/lib64/libm-2.17.so
0x7f9b846c7000-0x7f9b846e7000 /usr/lib64/ld-2.17.so
0x7f9b8475c000-0x7f9b848cb000
0x7f9b848cb000-0x7f9b848e6000
0x7f9b848e6000-0x7f9b848e7000 /usr/lib64/ld-2.17.so
0x7f9b848e7000-0x7f9b848e8000 /usr/lib64/ld-2.17.so
0x7f9b848e8000-0x7f9b848e9000
0x7ffd55c95000-0x7ffd55cb6000 [stack]
0x7ffd55cfb000-0x7ffd55cfd000 [vdso]
0xffffffffff600000-0xffffffffff601000 [vsyscall]
==2892==End of process memory map.
==2892==AddressSanitizer CHECK failed:
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:120
"((0 && "unable to mmap")) != (0)" (0x0, 0x0)
#0 0x4ea5bf in __asan::AsanCheckFailed(char const*, int, char const*,
unsigned long long, unsigned long long)
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/asan/asan_rtl.cc:69
#1 0x501ee5 in __sanitizer::CheckFailed(char const*, int, char const*,
unsigned long long, unsigned long long)
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:79
#2 0x4f2b80 in __sanitizer::ReportMmapFailureAndDie(unsigned long, char
const*, char const*, int, bool)
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:120
#3 0x4fb35e in __sanitizer::MmapOrDie(unsigned long, char const*, bool)
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix.cc:132
#4 0x42660f in
__sanitizer::LargeMmapAllocator<__asan::AsanMapUnmapCallback>::Allocate(__sanitizer::AllocatorStats*,
unsigned long, unsigned long)
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_secondary.h:41
#5 0x42660f in
__sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__asan::AP64>,
__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64>
>, __sanitizer::LargeMmapAllocator<__asan::AsanMapUnmapCallback>
>::Allocate(__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64>
>*, unsigned long, unsigned long, bool, bool)
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_combined.h:70
#6 0x42660f in __asan::Allocator::Allocate(unsigned long, unsigned
long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool)
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/asan/asan_allocator.cc:407
#7 0x4dff89 in malloc
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:67
#8 0x5411c9 in quicktime_read_info
/home/test/Downloads/libquicktime-1.2.4/src/lqt_quicktime.c:1784:39
#9 0x5441ca in do_open
/home/test/Downloads/libquicktime-1.2.4/src/lqt_quicktime.c:2026:10
#10 0x515a55 in file_info
/home/test/Downloads/libquicktime-1.2.4/utils/qtinfo.c:45:12
#11 0x515a55 in main
/home/test/Downloads/libquicktime-1.2.4/utils/qtinfo.c:69
#12 0x7f9b835d1b34 in __libc_start_main
/usr/src/debug/glibc-2.17-c758a686/csu/../csu/libc-start.c:274
#13 0x41affb in _start
(/home/test/Downloads/libquicktime-afl-build/bin/qtinfo+0x41affb)
The poc is attachment.
Credit : ADLab of Venustech
|
|
From: haojun h. <hao...@gm...> - 2017-06-11 15:52:17
|
On libquicktime 1.2.4, a crafted file revealed an allocation failed in the
function quicktime_read_ftyp .
#qtinfo $POC
==2703==ERROR: AddressSanitizer failed to allocate 0x1e0003000 (8053075968)
bytes of LargeMmapAllocator (error code: 12)
==2703==Process memory map follows:
0x000000400000-0x0000008b5000
/home/test/Downloads/libquicktime-afl-build/bin/qtinfo
0x000000ab5000-0x000000ab6000
/home/test/Downloads/libquicktime-afl-build/bin/qtinfo
0x000000ab6000-0x000000ad2000
/home/test/Downloads/libquicktime-afl-build/bin/qtinfo
0x000000ad2000-0x000001739000
0x00007fff7000-0x00008fff7000
0x00008fff7000-0x02008fff7000
0x02008fff7000-0x10007fff8000
0x600000000000-0x604000000000
0x604000000000-0x604000010000
0x604000010000-0x604e00000000
0x604e00000000-0x604e00010000
0x604e00010000-0x606000000000
0x606000000000-0x606000010000
0x606000010000-0x606e00000000
0x606e00000000-0x606e00010000
0x606e00010000-0x608000000000
0x608000000000-0x608000010000
0x608000010000-0x608e00000000
0x608e00000000-0x608e00010000
0x608e00010000-0x616000000000
0x616000000000-0x616000010000
0x616000010000-0x616e00000000
0x616e00000000-0x616e00010000
0x616e00010000-0x624000000000
0x624000000000-0x624000010000
0x624000010000-0x624e00000000
0x624e00000000-0x624e00010000
0x624e00010000-0x626000000000
0x626000000000-0x626000010000
0x626000010000-0x626e00000000
0x626e00000000-0x626e00010000
0x626e00010000-0x640000000000
0x640000000000-0x640000003000
0x7efc08900000-0x7efc08a00000
0x7efc08b00000-0x7efc08c00000
0x7efc08d00000-0x7efc08e00000
0x7efc08f00000-0x7efc09000000
0x7efc090de000-0x7efc0b430000
0x7efc0b430000-0x7efc0b5e6000 /usr/lib64/libc-2.17.so
0x7efc0b5e6000-0x7efc0b7e6000 /usr/lib64/libc-2.17.so
0x7efc0b7e6000-0x7efc0b7ea000 /usr/lib64/libc-2.17.so
0x7efc0b7ea000-0x7efc0b7ec000 /usr/lib64/libc-2.17.so
0x7efc0b7ec000-0x7efc0b7f1000
0x7efc0b7f1000-0x7efc0b806000 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
0x7efc0b806000-0x7efc0ba05000 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
0x7efc0ba05000-0x7efc0ba06000 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
0x7efc0ba06000-0x7efc0ba07000 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
0x7efc0ba07000-0x7efc0ba0e000 /usr/lib64/librt-2.17.so
0x7efc0ba0e000-0x7efc0bc0d000 /usr/lib64/librt-2.17.so
0x7efc0bc0d000-0x7efc0bc0e000 /usr/lib64/librt-2.17.so
0x7efc0bc0e000-0x7efc0bc0f000 /usr/lib64/librt-2.17.so
0x7efc0bc0f000-0x7efc0bc26000 /usr/lib64/libpthread-2.17.so
0x7efc0bc26000-0x7efc0be25000 /usr/lib64/libpthread-2.17.so
0x7efc0be25000-0x7efc0be26000 /usr/lib64/libpthread-2.17.so
0x7efc0be26000-0x7efc0be27000 /usr/lib64/libpthread-2.17.so
0x7efc0be27000-0x7efc0be2b000
0x7efc0be2b000-0x7efc0be2d000 /usr/lib64/libdl-2.17.so
0x7efc0be2d000-0x7efc0c02d000 /usr/lib64/libdl-2.17.so
0x7efc0c02d000-0x7efc0c02e000 /usr/lib64/libdl-2.17.so
0x7efc0c02e000-0x7efc0c02f000 /usr/lib64/libdl-2.17.so
0x7efc0c02f000-0x7efc0c044000 /usr/lib64/libz.so.1.2.7
0x7efc0c044000-0x7efc0c243000 /usr/lib64/libz.so.1.2.7
0x7efc0c243000-0x7efc0c244000 /usr/lib64/libz.so.1.2.7
0x7efc0c244000-0x7efc0c245000 /usr/lib64/libz.so.1.2.7
0x7efc0c245000-0x7efc0c345000 /usr/lib64/libm-2.17.so
0x7efc0c345000-0x7efc0c545000 /usr/lib64/libm-2.17.so
0x7efc0c545000-0x7efc0c546000 /usr/lib64/libm-2.17.so
0x7efc0c546000-0x7efc0c547000 /usr/lib64/libm-2.17.so
0x7efc0c547000-0x7efc0c567000 /usr/lib64/ld-2.17.so
0x7efc0c5dc000-0x7efc0c74b000
0x7efc0c74b000-0x7efc0c766000
0x7efc0c766000-0x7efc0c767000 /usr/lib64/ld-2.17.so
0x7efc0c767000-0x7efc0c768000 /usr/lib64/ld-2.17.so
0x7efc0c768000-0x7efc0c769000
0x7ffce97d5000-0x7ffce97f6000 [stack]
0x7ffce97f8000-0x7ffce97fa000 [vdso]
0xffffffffff600000-0xffffffffff601000 [vsyscall]
==2703==End of process memory map.
==2703==AddressSanitizer CHECK failed:
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:120
"((0 && "unable to mmap")) != (0)" (0x0, 0x0)
#0 0x4ea5bf in __asan::AsanCheckFailed(char const*, int, char const*,
unsigned long long, unsigned long long)
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/asan/asan_rtl.cc:69
#1 0x501ee5 in __sanitizer::CheckFailed(char const*, int, char const*,
unsigned long long, unsigned long long)
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:79
#2 0x4f2b80 in __sanitizer::ReportMmapFailureAndDie(unsigned long, char
const*, char const*, int, bool)
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:120
#3 0x4fb35e in __sanitizer::MmapOrDie(unsigned long, char const*, bool)
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix.cc:132
#4 0x42660f in
__sanitizer::LargeMmapAllocator<__asan::AsanMapUnmapCallback>::Allocate(__sanitizer::AllocatorStats*,
unsigned long, unsigned long)
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_secondary.h:41
#5 0x42660f in
__sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__asan::AP64>,
__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64>
>, __sanitizer::LargeMmapAllocator<__asan::AsanMapUnmapCallback>
>::Allocate(__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64>
>*, unsigned long, unsigned long, bool, bool)
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_combined.h:70
#6 0x42660f in __asan::Allocator::Allocate(unsigned long, unsigned
long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool)
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/asan/asan_allocator.cc:407
#7 0x4dff89 in malloc
/home/test/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:67
#8 0x574538 in quicktime_read_ftyp
/home/test/Downloads/libquicktime-1.2.4/src/ftyp.c:148:29
#9 0x5410c5 in quicktime_read_info
/home/test/Downloads/libquicktime-1.2.4/src/lqt_quicktime.c:1774:15
#10 0x5441ca in do_open
/home/test/Downloads/libquicktime-1.2.4/src/lqt_quicktime.c:2026:10
#11 0x515a55 in file_info
/home/test/Downloads/libquicktime-1.2.4/utils/qtinfo.c:45:12
#12 0x515a55 in main
/home/test/Downloads/libquicktime-1.2.4/utils/qtinfo.c:69
#13 0x7efc0b451b34 in __libc_start_main
/usr/src/debug/glibc-2.17-c758a686/csu/../csu/libc-start.c:274
#14 0x41affb in _start
(/home/test/Downloads/libquicktime-afl-build/bin/qtinfo+0x41affb)
The poc is attachment.
Credit : ADLab of Venustech
|
|
From: haojun h. <hao...@gm...> - 2017-06-11 04:15:09
|
help 2017-06-10 20:05 GMT+08:00 <lib...@li... >: > Send Libquicktime-devel mailing list submissions to > lib...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/libquicktime-devel > or, via email, send a message with subject or body 'help' to > lib...@li... > > You can reach the person managing the list at > lib...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Libquicktime-devel digest..." > > > Today's Topics: > > 1. CVE-2017-9122 - CVE-2017-9128 libquicktime multiple > vulnerabilities (Henri Salo) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 10 Jun 2017 11:15:37 +0300 > From: Henri Salo <he...@ne...> > To: lib...@li... > Subject: [Libquicktime-devel] CVE-2017-9122 - CVE-2017-9128 > libquicktime multiple vulnerabilities > Message-ID: <20170610081537.GA18581@tunkki> > Content-Type: text/plain; charset=us-ascii > > Advisory is posted in here: http://lists.openwall.net/ > full-disclosure/2017/06/08/2 > > -- > Henri Salo > > > > ------------------------------ > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Libquicktime-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libquicktime-devel > > > ------------------------------ > > End of Libquicktime-devel Digest, Vol 86, Issue 1 > ************************************************* > |
|
From: Henri S. <he...@ne...> - 2017-06-10 08:33:40
|
Advisory is posted in here: http://lists.openwall.net/full-disclosure/2017/06/08/2 -- Henri Salo |
|
From: Burkhard P. <bur...@ig...> - 2017-03-06 17:35:57
|
Hi, Am 05.03.2017 um 22:51 schrieb Bálint Réczey: > Hi, > > Please see the Debian bug at: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855099 > > Also please see a fairly minimal patch attached. > > Cheers, > Balint > Applied. Burkhard |
|
From: Bálint R. <ba...@ba...> - 2017-03-05 21:52:01
|
Hi, Please see the Debian bug at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855099 Also please see a fairly minimal patch attached. Cheers, Balint ---------- Forwarded message ---------- From: Salvatore Bonaccorso <ca...@de...> Date: 2017-02-14 5:54 GMT+01:00 Subject: Bug#855099: libquicktime: CVE-2016-2399 To: Debian Bug Tracking System <su...@bu...> Source: libquicktime Version: 2:1.2.4-7 Severity: important Tags: security upstream Hi, the following vulnerability was published for libquicktime. CVE-2016-2399[0]: | Integer overflow in the quicktime_read_pascal function in libquicktime | 1.2.4 and earlier allows remote attackers to cause a denial of service | or possibly have other unspecified impact via a crafted hdlr MP4 atom. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2016-2399 Regards, Salvatore |
|
From: Burkhard P. <bur...@ig...> - 2016-04-26 17:52:28
|
Hi, Am 21.04.2016 um 13:15 schrieb Erik Johansson: [...] > Attaching a patch to change quicktime_read_int32, > quicktime_read_int32_le & quicktime_read_uint32 to use int32_t and > uint32_t instead of long. Applied. BTW I'm sure, there are many more places in the code, which use long. Burkhard |
|
From: Burkhard P. <bur...@ig...> - 2016-04-26 17:48:28
|
Hi, Am 22.04.2016 um 10:02 schrieb Erik Johansson: > Hello, > > I was provided with a sample file which contains all open-GOP MPEG2 > essence. The structure of the file is IBBPBB... where the first two > B-frames reference a non existing keyframe. These two broken frames > are ignored thanks to an edts entry. The stss atom is empty as there > are only partial sync samples. > > The problem I found is that packet_index_create_video() marks all > frames as keyframes when there are not stss entries. Trivial fix: > > - else if(!stss) > + else if(!stss && !stps) > > Patch attached > Applied. Burkhard |
22 messages has been excluded from this view by a project administrator.