Bug#773929: unzip: uninitialised read in getZip64Data

[Lorenz H-S]

Package: unzip
Version: 6.0-13
Severity: normal
Tags: upstream

Dear Maintainer,

using the american fuzzy lop fuzzer, I managed to find a zip file that results
in an uninitialised read in getZip64Data. This is not the same issue as
CVE-2014-8141 and is still present in unzip 6.0-13.

The zip file in question and a valgrind log are attached.

Cheers,
Lorenz Hübschle-Schneider



-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.18.1-cust+ (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages unzip depends on:
ii  libbz2-1.0  1.0.6-7+b2
ii  libc6   2.19-13

unzip recommends no packages.

Versions of packages unzip suggests:
ii  zip  3.0-8




*** /tmp/unzip-valgrind.txt
==32565== Memcheck, a memory error detector
==32565== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==32565== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==32565== Command: ./unzip -d /tmp/dump -o -P
c/id:00,sig:00,sync:f20,src:78
==32565==
Archive:  c/id:00,sig:00,sync:f20,src:78
error [c/id:00,sig:00,sync:f20,src:78]:  missing 19 bytes in zipfile
  (attempting to process anyway)
error [c/id:00,sig:00,sync:f20,src:78]:  reported length of central
directory is
  19 bytes too long (Atari STZip zipfile?  J.H.Holm ZIPSPLIT 1.1
  zipfile?).  Compensating...
==32565== Conditional jump or move depends on uninitialised value(s)
==32565==at 0x40FFB6: getZip64Data (process.c:1927)
==32565==by 0x40A48F: do_string (fileio.c:2300)
==32565==by 0x40832F: extract_or_test_files (extract.c:503)
==32565==by 0x40F119: do_seekable (process.c:987)
==32565==by 0x40F7BD: process_zipfiles (process.c:401)
==32565==by 0x403433: unzip (unzip.c:1253)
==32565==by 0x403487: main (unzip.c:720)
==32565==  Uninitialised value was created by a heap allocation
==32565==at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-
amd64-linux.so)
==32565==by 0x40A3FA: do_string (fileio.c:2289)
==32565==by 0x40832F: extract_or_test_files (extract.c:503)
==32565==by 0x40F119: do_seekable (process.c:987)
==32565==by 0x40F7BD: process_zipfiles (process.c:401)
==32565==by 0x403433: unzip (unzip.c:1253)
==32565==by 0x403487: main (unzip.c:720)
==32565==
==32565== Conditional jump or move depends on uninitialised value(s)
==32565==at 0x40FFC1: getZip64Data (process.c:1935)
==32565==by 0x40A48F: do_string (fileio.c:2300)
==32565==by 0x40832F: extract_or_test_files (extract.c:503)
==32565==by 0x40F119: do_seekable (process.c:987)
==32565==by 0x40F7BD: process_zipfiles (process.c:401)
==32565==by 0x403433: unzip (unzip.c:1253)
==32565==by 0x403487: main (unzip.c:720)
==32565==  Uninitialised value was created by a heap allocation
==32565==at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-
amd64-linux.so)
==32565==by 0x40A3FA: do_string (fileio.c:2289)
==32565==by 0x40832F: extract_or_test_files (extract.c:503)
==32565==by 0x40F119: do_seekable (process.c:987)
==32565==by 0x40F7BD: process_zipfiles (process.c:401)
==32565==by 0x403433: unzip (unzip.c:1253)
==32565==by 0x403487: main (unzip.c:720)
==32565==
==32565== Conditional jump or move depends on uninitialised value(s)
==32565==at 0x4100A5: getZip64Data (process.c:1922)
==32565==by 0x40A48F: do_string (fileio.c:2300)
==32565==by 0x40832F: extract_or_test_files (extract.c:503)
==32565==by 0x40F119: do_seekable (process.c:987)
==32565==by 0x40F7BD: process_zipfiles (process.c:401)
==32565==by 0x403433: unzip (unzip.c:1253)
==32565==by 0x403487: main (unzip.c:720)
==32565==  Uninitialised value was created by a heap allocation
==32565==at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-
amd64-linux.so)
==32565==by 0x40A3FA: do_string (fileio.c:2289)
==32565==by 0x40832F: extract_or_test_files (extract.c:503)
==32565==by 0x40F119: do_seekable (process.c:987)
==32565==by 0x40F7BD: process_zipfiles (process.c:401)
==32565==by 0x403433: unzip (unzip.c:1253)
==32565==by 0x403487: main (unzip.c:720)
==32565==
==32565== Use of uninitialised value of size 8
==32565==at 0x40A544: makeword (fileio.c:2426)
==32565==by 0x40FF9F: getZip64Data (process.c:1924)
==32565==by 0x40A48F: do_string (fileio.c:2300)
==32565==by 0x40832F: extract_or_test_files (extract.c:503)
==32565==by 0x40F119: do_seekable (process.c:987)
==32565==by 0x40F7BD: process_zipfiles (process.c:401)
==32565==by 0x403433: unzip (unzip.c:1253)
==32565==by 0x403487: main (unzip.c:720)
==32565==  Uninitialised value was created by a heap allocation
==32565==at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-
amd64-linux.so)
==32565=

Bug#736412: Chromium Thumbnails Bug

[Lorenz H.-S.]

Dear Eugenio,

I've been experiencing the same issue for quite a while (since Chromium 24,
actually) and filed a bug upstream, which will celebrate its first birthday
tomorrow:

https://code.google.com/p/chromium/issues/detail?id=176507

It hasn't occurred in quite a while for me, though.

Cheers,
Lorenz

Bug#717317: aptitude: segfault when choosing Views -> New Categorical Browser in ncurses interface

[Lorenz H-S]

Package: aptitude
Version: 0.6.8.2-1
Severity: normal

Dear Maintainer,

upon choosing Views -> New Categorical Browser in aptitude's ncurses inferace,
it crashes reprocducibly with a segmentation fault. You can find a full
backtrace attached; the segfault occurs in Thread #1. No prior action in
aptitude is required to trigger this bug. My system has an Intel Core i5-2520M
CPU with SSE 4.2 support.

Program received signal SIGSEGV, Segmentation fault.
__strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:236
236 movdqa  (%rsi), %xmm1



thread apply all bt:
===

Thread 5 (Thread 0x7f92a4bd0700 (LWP 25045)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
.../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7f92a7b3ac47 in cwidget::toplevel::input_thread::operator()() () from
/usr/lib/libcwidget.so.3
#2  0x7f92a7b3ad31 in void*
cwidget::threads::thread::bootstrap
>(void*) () from /usr/lib/libcwidget.so.3
#3  0x7f92a6b62e0e in start_thread (arg=0x7f92a4bd0700) at
pthread_create.c:311
#4  0x7f92a608093d in clone () at
.../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 4 (Thread 0x7f92a43cf700 (LWP 25046)):
#0  do_sigwait (set=, sig=0x7f92a43ced4c) at
.../nptl/sysdeps/unix/sysv/linux/../../../../../sysdeps/unix/sysv/linux/sigwait.c:64
#1  0x7f92a6b69fdb in __sigwait (set=, sig=)
at
.../nptl/sysdeps/unix/sysv/linux/../../../../../sysdeps/unix/sysv/linux/sigwait.c:99
#2  0x7f92a7b32832 in ?? () from /usr/lib/libcwidget.so.3
#3  0x7f92a7b3a86e in void*
cwidget::threads::thread::bootstrap(void*) ()
from /usr/lib/libcwidget.so.3
#4  0x7f92a6b62e0e in start_thread (arg=0x7f92a43cf700) at
pthread_create.c:311
#5  0x7f92a608093d in clone () at
.../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 3 (Thread 0x7f92a3bce700 (LWP 25047)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
.../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7f92a7b3bc64 in void*
cwidget::threads::thread::bootstrap
>(void*) () from /usr/lib/libcwidget.so.3
#2  0x7f92a6b62e0e in start_thread (arg=0x7f92a3bce700) at
pthread_create.c:311
#3  0x7f92a608093d in clone () at
.../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 2 (Thread 0x7f929f39c700 (LWP 25051)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
.../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7f92a8bf64d8 in wait (l=...,
this=0x7f92aa46e268) at /usr/include/cwidget/generic/threads/threads.h:508
#2  resolver_manager::background_thread_execution
(this=this@entry=0x7f92aa46e150) at
.../../../../src/generic/apt/resolver_manager.cc:569
#3  0x7f92a8c4dc31 in operator() (this=) at
.../../../../src/generic/apt/resolver_manager.cc:709
#4
cwidget::threads::thread::bootstrap
(p=) at /usr/include/cwidget/generic/threads/threads.h:117
#5  0x7f92a6b62e0e in start_thread (arg=0x7f929f39c700) at
pthread_create.c:311
#6  0x7f92a608093d in clone () at
.../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 1 (Thread 0x7f92a895f780 (LWP 25044)):
#0  __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:236
#1  0x7f92a8aaf523 in do_compare (ver2=..., pkg2=..., ver1=..., pkg1=...,
this=0x7f92aa7fcc30) at ../../src/pkg_sortpolicy.cc:128
#2  pkg_sortpolicy_name_impl::compare (this=0x7f92aa7fcc30, pkg1=..., ver1=...,
pkg2=..., ver2=...) at ../../src/pkg_sortpolicy.cc:128
#3  0x7f92a8aaf194 in pkg_sortpolicy_wrapper::compare (this=0x7fff4d4ac400,
item1=0x7f92ace46f70, item2=0x7f92ace46df0) at ../../src/pkg_sortpolicy.cc:118
#4  0x7f92a8a69029 in pkg_sortpolicy_wrapper::operator() (this=, item1=, item2=) at
.../../src/pkg_sortpolicy.h:83
#5  0x7f92a8a6b6b5 in operator() (item2=, item1=, this=) at /usr/include/cwidget/widgets/treeitem.h:410
#6  std::list
>::merge (this=0x7fff4d4abec0, __x=...,
__comp=...) at /usr/include/c++/4.7/bits/list.tcc:339
#7  0x7f92a8a6b7c3 in std::list >::sort
(this=this@entry=0x7f92ac35c460, __comp=__comp@entry=...)
at /usr/include/c++/4.7/bits/list.tcc:451
#8  0x7f92a8a6b8f2 in cwidget::widgets::subtree::sort (this=0x7f92ac35c450, sort_method=...)
at /usr/include/cwidget/widgets/subtree.h:175
#9  0x7f92a8a6b8df in cwidget::widgets::subtree::sort (this=0x7f92ac09c7a0, sort_method=...)
at /usr/include/cwidget/widgets/subtree.h:173
#10 0x7f92a8ab47bf in pkg_tree::build_tree (this=this@entry=0x7f92ac09bab0,
progress=...) at ../../src/pkg_tree.cc:242
#11 0x7f92a8ab4d56 in pkg_tree::build_tree (this=this@entry=0x7f92ac09bab0)
at ../../src/pkg_tree.cc:261
#12 0x7f92a8ab51d5 in pkg_tree::set_limit (this=0x7f92ac09bab0, _limit=...)
at ../../src/pkg_tree.cc:278
#13 0x7f92a8af9d52 in do_new_hier_view (progress=...) at
.../../src/ui.cc:946
#14 0x7f92a8afa081 in do_new_hier_view_with_new_bar () at
.../../src/ui.cc:962
#15 0x7f92a7b5faaa in cwidget::widgets::menu::dispatch_mouse(short, int,
int, int, unsigned long) () from /usr/lib/libcwidget.so.3
#16 0x7f92a7b69265 in cwidget::widgets::menubar

Bug#702581: vlc: VLC crashes in libeml on some video files (mkv, h.264)

[Lorenz H.-S.]

Alright, some new insights. libebml is trying to allocate 3219169814460
bytes (src/EbmlBinary.cpp:97), but it gets this number from libmatroska
(src/KaxBlock.cpp:458). My guess is that the KaxSimpleBlock's size is
incorrect in the file.

In modules/demux/mkv/matroska_segment.cpp:1558
(matroska_segment_c::BlockGet):
(gdb) ins *el
$11 = {_vptr.EbmlElement = 0x7fffe2461510, Size = 3219169814460,
DefaultSize = 0, SizeLength = 6, bSizeIsFinite = true, ElementPosition =
135411848, SizePosition = 135411849, bValueIsSet = false, DefaultIsSet =
false, bLocked = false}

One further up, in modules/demux/mkv/mkv.cpp:692 (Demux):

(gdb) ins *simpleblock
$14 = { = { =
{ = {_vptr.EbmlElement = 0x7fffe2461510, Size =
3219169814460, DefaultSize = 0, SizeLength = 6, bSizeIsFinite = true,
ElementPosition = 135411848,
SizePosition = 135411849, bValueIsSet = false, DefaultIsSet =
false, bLocked = false}, Data = 0x0}, myBuffers =
{ >> = {
_M_impl = {> =
{<__gnu_cxx::new_allocator> = {},
}, _M_start = 0x0, _M_finish = 0x0,
  _M_end_of_storage = 0x0}}, }, SizeList =
{ >> = {_M_impl =
{> = {<__gnu_cxx::new_allocator> = {}, },
  _M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}}, }, Timecode = 4, LocalTimecode = 0, bLocalTimecodeUsed = false,
TrackNumber = 13057, mLacing = libmatroska::LACING_AUTO, mInvisible =
false,
FirstFrameLocation = 135411855, ParentCluster = 0x0, bIsSimple = true,
bIsKeyframe = true, bIsDiscardable = false}, static ClassInfos = {Create =
0x7fffe221e831 , GlobalId =
@0x7fffe2470b50,
DebugName = 0x7fffe2243ec7 "SimpleBlock", Context = @0x7fffe2470b60}}


Up again, to input/demux.h:44

(gdb) ins *p_demux
$17 = {psz_object_type = 0x7799a1d9 "demux", psz_header = 0x0, i_flags
= 0, b_die = false, b_force = false, p_libvlc = 0x605108, p_parent =
0x6387b8, p_module = 0x751860, psz_access = 0x67fc80 "file", psz_demux =
0x67f390 "",
  psz_location = 0x67f040 "/media/STORE/foo.mkv", psz_file = 0x67eee0
"/media/STORE/foo.mkv", s = 0x68d028, out = 0x68c810, pf_demux =
0x7fffe2480c50 ,
  pf_control = 0x7fffe247f6e0 , info = {i_update = 0, i_title = 0,
i_seekpoint = 0}, p_sys = 0x68d1f0, p_input = 0x6387b8}
(gdb) ins *p_demux->p_sys
$18 = {player = 0x7fffe26b7690, config = {clockDefault = 6869336,
clockForced = false, clockSpeed = 7257000, environment = sid2_envPS,
forceDualSids = 112, emulateStereo = 232, frequency = 0, optimisation = 0
'\000',
playback = sid2_left, precision = 0, sidDefault = SID2_MODEL_CORRECT,
sidEmulation = 0x69d330, sidModel = 6777344, sidSamples = false, leftVolume
= 6777352, rightVolume = 0, sampleFormat = 6777352, powerOnDelay = 0,
sid2crcCount = 0}, info = {credits = 0x686850, channels = 6842456,
driverAddr = 0, driverLength = 0, name = 0x686858 "", tuneInfo = 0x0,
version = 0x0, eventContext = 0x0, maxsids = 6798144, environment =
sid2_envPS,
powerOnDelay = 47944, sid2crc = 0, sid2crcCount = 6798152}, tune =
0x6828f0, tuneInfo = {formatString = 0x6828f8 "", statusString = 0x6828f8
"", speedString = 0x69d1b0 "P*h", loadAddr = 0, initAddr = 0, playAddr = 0,
songs = 0,
startSong = 0, sidChipBase1 = 0, sidChipBase2 = 0, currentSong = 0,
songSpeed = 0 '\000', clockSpeed = 0 '\000', relocStartPage = 0 '\000',
relocPages = 0 '\000', musPlayer = false, sidModel = 0, compatibility = 0,
fixLoad = false,
songLength = 0, numberOfInfoStrings = 0 '\000', infoString = {0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, numberOfCommentStrings = 0,
commentString = 0x0, dataFileLen = 0, c64dataLen = 0, path = 0x0,
dataFileName = 0x0,
infoFileName = 0x0}, bytes_per_frame = 0, block_size = 0, es = 0x0, pts
= {date = 0, i_divider_num = 0, i_divider_den = 0, i_remainder = 0}}
(gdb) ins *p_demux->p_sys->p_current_segment
There is no member named p_current_segment.

That last line seems a bit strange to me, but then I'm not familiar with
vlc's codebase at all. I'd be happy to try out any suggestions you may have.

Kind regards,
Lorenz

Bug#702581: vlc: VLC crashes in libeml on some video files (mkv, h.264)

[Lorenz H.-S.]

Thank you for your response. First, a proper bug report following the
guidelines:

I am trying to play a video file. It's an h264, 720p video stream in a
matroska container. The file is 1744119808 Bytes (1.7GB) large.
When I try to play it in vlc (vlc foo.mkv), it crashes at the same point
some 5 to 7 seconds into the file every time. A gdb session with
disassembly and a register dump for vlc as suggested for avplay (which does
not crash, output below) is further below.
vlc --verbose 2 foo.mkv: http://bpaste.net/show/82438/
valgrind foo.mkv: http://bpaste.net/show/82436/
valgrind -v foo.mkv: http://bpaste.net/show/AWprB2k03dpY2ilhU3cA/

When I try to reproduce the problem in vlc with a non-huge sample of the
file, no crash occurs.
The crash in vlc does not occur with a 264062 kiB sample.
It does occur with a 264843 kiB sample.

I hope this helps.

Kind regards,
Lorenz

** The avplay output:

avplay version 0.8.5-6:0.8.5-1, Copyright (c) 2003-2012 the Libav developers
  built on Jan 13 2013 12:05:48 with gcc 4.7.2
[matroska,webm @ 0x955360] Estimating duration from bitrate, this may be
inaccurate
Input #0, matroska,webm, from 'foo.mkv':
  Duration: 00:43:47.33, start: 0.00, bitrate: 384 kb/s
Stream #0.0(eng): Video: h264 (High), yuv420p, 1280x720, PAR 1:1 DAR
16:9, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc
Stream #0.1: Audio: ac3, 48000 Hz, stereo, s16, 384 kb/s (default)
[matroska,webm @ 0x955360] Unknown entry 0xBDKB sq=0B f=0/0   f=0/0
[matroska,webm @ 0x955360] Unknown entry 0x89KB sq=0B f=0/0
[matroska,webm @ 0x955360] Unknown entry 0xB1
[matroska,webm @ 0x955360] Invalid EBML number size tag 0x06 at pos
53004489 (0x328c8c9)
[h264 @ 0x1247ec0] Reference 2 >= 2B vq=  200KB sq=0B f=0/0
[h264 @ 0x1247ec0] error while decoding MB 40 23, bytestream (64205)
[h264 @ 0x1247ec0] concealing 1769 DC, 1769 AC, 1769 MV errors
^C 7.43 A-V: -4.511 s:0.0 aq=0KB vq=0KB sq=0B f=0/0


At that point, it hangs.


** vlc gdb session with disassembly and register dump:

GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/vlc...Reading symbols from
/usr/lib/debug/usr/bin/vlc...done.
done.
(gdb) run
Starting program: /usr/bin/vlc foo.mkv
warning: no loadable sections found in added symbol-file system-supplied
DSO at 0x77ffa000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffee855700 (LWP 11938)]
[New Thread 0x7fffec8f4700 (LWP 11939)]
[0x605108] main libvlc: Running vlc with the default interface. Use 'cvlc'
to use vlc without interface.
[New Thread 0x7fffe9a48700 (LWP 11940)]
[New Thread 0x7fffe2065700 (LWP 11941)]
[Thread 0x7fffec8f4700 (LWP 11939) exited]
[Thread 0x7fffe2065700 (LWP 11941) exited]
[New Thread 0x7fffe2065700 (LWP 11942)]
[New Thread 0x7fffec8f4700 (LWP 11943)]
[New Thread 0x7fffd4195700 (LWP 11944)]
[New Thread 0x7fffcc8bd700 (LWP 11945)]
[New Thread 0x7fffc462c700 (LWP 11946)]
[New Thread 0x7fffd56dd700 (LWP 11947)]
terminate called after throwing an instance of 'libebml::CRTError'
  what():  Error allocating data: Cannot allocate memory

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe2065700 (LWP 11942)]
0x769c2475 in *__GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x769c2475 in *__GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x769c56f0 in *__GI_abort () at abort.c:92
#2  0x7721789d in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x77215996 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x772159c3 in std::terminate() () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x77215bee in __cxa_throw () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x7fffe80313c6 in
libebml::EbmlBinary::ReadData(libebml::IOCallback&, libebml::ScopeMode) ()
from /usr/lib/x86_64-linux-gnu/libebml.so.3
#7  0x7fffe3b7a500 in
libmatroska::KaxInternalBlock::ReadData(libebml::IOCallback&,
libebml::ScopeMode) () from /usr/lib/x86_64-linux-gnu/libmatroska.so.5
#8  0x7fffe3dcf592 in matroska_segment_c::BlockGet (this=0xa8d9b0,
pp_block=, pp_simpleblock=,
pb_key_picture=, pb_discardable_picture=0x7fffe2064d67,
pi_duration=0x7fffe2064d78)
at matroska_segment.cpp:1558
#9  0x7fffe3dc6d1e in Demux (p_demux=0x7fffdcb8) at mkv.cpp:692
#10 0x7792f40b in demux_Demux (p_demux=0x7fffdcb8) at

Bug#702581: vlc: VLC crashes in libeml on some video files (mkv, h.264)

[Lorenz H-S]

Package: vlc
Version: 2.0.5-1
Severity: important
Tags: upstream

Dear Maintainer,

vlc reproducibly crashes each time at exactly the same position a few seconds
into a broken matroska file. A full backtrace from a gdb session is attached.
Unfortunately, I cannot share the file publicly for copyright reasons.

mplayer2 cannot play the file either, but plays an additional second or so. A
log of that is attached as well. I do not dispute the fact that the file is
broken, but VLC's error handling should catch that and exit gracefully.

Should you need more information, I am happy to help you in any way possible.

Thank you!

Lorenz

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8.2-cust (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages vlc depends on:
ii  dpkg  1.16.9
ii  fonts-freefont-ttf20120503-1
ii  libaa11.4p5-40
ii  libavcodec53  7:0.10.3-dmo1
ii  libavutil51   8:1.0.5-dmo1
ii  libc6 2.13-38
ii  libcaca0  0.99.beta18-1
ii  libfreetype6  2.4.9-1.1
ii  libfribidi0   0.19.2-3
ii  libgcc1   1:4.7.2-5
ii  libgl1-mesa-glx [libgl1]  8.0.5-3
ii  libice6   2:1.0.8-2
ii  libqtcore44:4.8.2+dfsg-11
ii  libqtgui4 4:4.8.2+dfsg-11
ii  libsdl-image1.2   1.2.12-2
ii  libsdl1.2debian   1.2.15-5
ii  libsm62:1.2.1-2
ii  libstdc++64.7.2-5
ii  libtar0   1.2.16-1
ii  libva-x11-1   1.0.15-4
ii  libva11.0.15-4
ii  libvlccore5   2.0.5-1
ii  libx11-6  2:1.5.0-1
ii  libxcb-composite0 1.8.1-2
ii  libxcb-keysyms1   0.3.9-1
ii  libxcb-randr0 1.8.1-2
ii  libxcb-render01.8.1-2
ii  libxcb-shape0 1.8.1-2
ii  libxcb-shm0   1.8.1-2
ii  libxcb-xfixes01.8.1-2
ii  libxcb-xv01.8.1-2
ii  libxcb1   1.8.1-2
ii  libxext6  2:1.3.1-2
ii  libxinerama1  2:1.1.2-1
ii  libxpm4   1:3.5.10-1
ii  vlc-nox   2.0.5-1
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages vlc recommends:
ii  vlc-plugin-notify  2.0.5-1
ii  vlc-plugin-pulse   2.0.5-1
ii  xdg-utils  1.1.0~rc1+git20111210-7

Versions of packages vlc suggests:
pn  videolan-doc  




*** /tmp/vlc
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/vlc...Reading symbols from
/usr/lib/debug/usr/bin/vlc...done.
done.
(gdb) run
Starting program: /usr/bin/vlc foo.mkv
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x77ffa000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
VLC media player 2.0.5 Twoflower (revision 2.0.5-0-g1661b7d)
[New Thread 0x7fffeddd1700 (LWP 8680)]
[New Thread 0x7fffec92e700 (LWP 8681)]
[0x605108] main libvlc: Running vlc with the default interface. Use 'cvlc' to
use vlc without interface.
[New Thread 0x7fffe9c85700 (LWP 8682)]
[New Thread 0x7fffe8118700 (LWP 8683)]
[Thread 0x7fffec92e700 (LWP 8681) exited]
[Thread 0x7fffe8118700 (LWP 8683) exited]
[New Thread 0x7fffe8118700 (LWP 8685)]
[NULL @ 0x6ad2a0] Value 4686111960511545344.00 for parameter 'b' out of
range
[NULL @ 0x6ad2a0] Value 4683532506232782848.00 for parameter 'ab' out of
range
[NULL @ 0x6ad2a0] Value 4705844345939427328.00 for parameter 'bt' out of
range
[NULL @ 0x6ad2a0] Value 4617315517961601024.00 for parameter 'me_method'
out of range
[NULL @ 0x6ad2a0] Value 4622945017495814144.00 for parameter 'g' out of
range
[NULL @ 0x6ad2a0] Value 4611686018427387904.00 for parameter 'qmin' out of
range
[NULL @ 0x6ad2a0] Value 4629418941960159232.00 for parameter 'qmax' out of
range
[NULL @ 0x6ad2a0] Value 4613937818241073152.00 for parameter 'qdiff' out of
range
[NULL @ 0x6ad2a0] Value -4616189618054758400.00 for parameter 'wpredp' out
of range
[NULL @ 0x6ad2a0] Value 4607182418800017408.00 for parameter 'bug' out of
range
[NULL @ 0x6ad2a0] Value 4607182418800017408.00 for parameter 'er' out of
range
[NULL @ 0x6ad2a0] Value 4607182418800017408.00 for parameter 'err_detect'
out of range
[NULL @ 0x6ad2a0]

Bug#656223: git: Git aliases are handled differently from the commands they are aliased to

[Lorenz H-S]

Package: git
Version: 1:1.7.9~rc1-1
Severity: normal
Tags: upstream

Dear Maintainer,

I have aliased "s" to "status" in my ~/.gitconfig and noticed that "git s"
produces output different from "git status" in a repo's .git folder.
This bug is fully reproducible in every repo I have tried.
It seems like git notices it is in a git repo, but cannot find its base
directory.

In particular, "git status" returns with 128 and prints "fatal: This operation
must be run in a work tree", while "git s" reports changes and the contents of
the .git folder as untracked files.
This becomes even weirder if the .git folder is somewhere else than the working
directory, as is the case with e.g. the Android sources. Then, it cannot find
the working directory at all and only reports the folder's contents as
untracked files. All the while, "git status" prints "fatal: This operation must
be run in a work tree.



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.1-cust (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages git depends on:
ii  git-man  1:1.7.9~rc1-1
ii  libc62.13-24
ii  libcurl3-gnutls  7.23.1-3
ii  liberror-perl0.17-1
ii  libexpat12.0.1-7.2
ii  perl-modules 5.14.2-6
ii  zlib1g   1:1.2.3.4.dfsg-3

Versions of packages git recommends:
ii  less 444-1
ii  openssh-client [ssh-client]  1:5.9p1-2
ii  patch2.6.1-2
ii  rsync3.0.9-1

Versions of packages git suggests:
pn  git-arch  
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
pn  git-email 
pn  git-gui   1:1.7.9~rc1-1
pn  git-svn   
pn  gitk  1:1.7.9~rc1-1
pn  gitweb



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#626604: xorg: X server disables mouse and keyboard upon starting (Thinkpad T420 4180W1H)

[Lorenz H.-S.]

Hi Cyril,

thank you so much! Everything works perfectly now.
Though effective, the solution is not all that intuitive, and the fact
that /run was introduced by Poettering only quite recently and thus is
not that well known doesn't help either ;)
So this bug should now be about the generation of flawed files in /run/udev.

Thanks again,
Lorenz Hübschle-Schneider



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#626604: Additional Information

[Lorenz H.-S.]

When using "Xorg -configure" and then "X -config /root/xorg.conf.new",
I get the following output to the command line:
> error setting MTRR (base = 0xc000, size = 0x03ff, type = 1) Invalid 
> argument (22)

Also, when using startx, I get "FATAL: Module fbcon not found", which
(I hope) should not be a problem since CONFIG_FRAMEBUFFER_CONSOLE=y in
the kernel config.

Any ideas on how to debug this are greatly appreciated :)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org