Reported by: Zhen Zhou, NSFOCUS Security

Romain Vimont authored 4 years ago and Hugo Beauzée-Luyssen committed 4 years ago

The function vlc_tls_GetLine() forgot to truncate the string if a line
sent by the server did not end with `\r\n`. As a consequence, it returned a
non-NUL-terminated string.

Signed-off-by: Hugo Beauzée-Luyssen <hugo@beauzee.fr>

Check whether vlc-cache-gen can actually be executed, to
detect whether it is available for the right architecture.

If it is not available, support the possibility to not
sign the plugins.dat cache file. Also support the case
the cache file is not there from the beginning.

Calling on the symlink replaces that symlink with the real file
with latest versions of that tool. This invalidated the
framework structure of the Sparkle.framework.

This partially reverts commit d3485272.

all good for 4 months

Calling front() on an empty container is undefined behavior

The longuest string is 26 characters long, not including terminal null
byte

Otherwise link might fail

We don't want the symbol to be mangled when building C++

No functional change

Using va_arg with the function pointer type spelled out can be
considered ill-formed as per C11 §7.16.1.1
See http://c-faq.com/varargs/funcptr.html

All checks were nested which was really hard to read and modify
correctly. Instead use a state variable to track the detection status
and chain AS_IF condition for each test.

When building on ArchLinux currently, the contrib was built even if
lua5.3 is installed. As at least Archlinux and Debian are exposing both
a luaX.Y.pc and lua.pc file for the latest supported version of lua,
detecting that the system version is correct through lua.pc should
also ensure that the latest compatible version is installed and used
instead.

The other checks are still needed as you can for example install lua5.2
(which will expose a lua5.2.pc file but no lua.pc file) without having
to install lua (5.3).

It is worth noticing that being able to use lua >= 5.1 doesn't mean any
version of lua >= 5.1 would be compatible. The source code is completely
compliant to those version and native builds will have no issues with
using a more recent version, but cross-compilation environment for 32bit
environment from a 64bit one won't and need the appropriate version to
be installed.

...and rename the library file, linking it with a $(PREFIX) path.

This avoid build issues on ArchLinux where system library could get
picked but contrib headers would be used anyway, leading to missing
symbols, though it's a bug if lua contrib is not used while being
available in the PREFIX.

This also enforce the usage of LUA_CFLAGS/LUA_LIBS and cleans up the
PREFIX directory.

luaL_setfuncs exists since lua5.2 and luaL_register was already
deprecated at that version. Using the luaL_register since Lua 5.2
prevents using the deprecated function but mostly also enforce the
future state of the code to be used on more platforms.

The commit a7d548db introduced a debug
message when trying to access a unknown configuration item but was
limited to strings.

This commit refactor the debug code into a local function and use it at
similar places where the same kind of failure could happen.

From asan report:

==774849==ERROR: AddressSanitizer: heap-use-after-free on address 0x6080000051a8 at pc 0x7f06d1d61af3 bp 0x7ffe464e1af0 sp 0x7ffe464e1ae0
WRITE of size 8 at 0x6080000051a8 thread T0
    #0 0x7f06d1d61af2 in vlc_atomic_rc_dec ../../include/vlc_atomic.h:58
    #1 0x7f06d1d61af2 in libvlc_release ../../lib/core.c:82
    #2 0x55bc01a4167c in QtVLCWidget::cleanup() ../qtvlcwidget.cpp:253
    #3 0x55bc01a439c1 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (QtVLCWidget::*)()>::call(void (QtVLCWidget::*)(), QtVLCWidget*, void**) /usr/include/qt/QtCore/qobjectdefs_impl.h:152
    #4 0x55bc01a439c1 in void QtPrivate::FunctionPointer<void (QtVLCWidget::*)()>::call<QtPrivate::List<>, void>(void (QtVLCWidget::*)(), QtVLCWidget*, void**) /usr/include/qt/QtCore/qobjectdefs_impl.h:185
    #5 0x55bc01a439c1 in QtPrivate::QSlotObject<void (QtVLCWidget::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) /usr/include/qt/QtCore/qobjectdefs_impl.h:418
    #6 0x7f06d0d86035  (/usr/lib/libQt5Core.so.5+0x2eb035)
    #7 0x7f06d116db79 in QOpenGLContext::destroy() (/usr/lib/libQt5Gui.so.5+0x180b79)
    #8 0x7f06d116de77 in QOpenGLContext::~QOpenGLContext() (/usr/lib/libQt5Gui.so.5+0x180e77)
    #9 0x7f06d116de99 in QOpenGLContext::~QOpenGLContext() (/usr/lib/libQt5Gui.so.5+0x180e99)
    #10 0x7f06d1874c0b  (/usr/lib/libQt5Widgets.so.5+0x1bac0b)
    #11 0x7f06d1874c94 in QOpenGLWidget::~QOpenGLWidget() (/usr/lib/libQt5Widgets.so.5+0x1bac94)
    #12 0x55bc01a430e1 in QtVLCWidget::~QtVLCWidget() ../qtvlcwidget.cpp:237
    #13 0x7f06d0d7936d in QObjectPrivate::deleteChildren() (/usr/lib/libQt5Core.so.5+0x2de36d)
    #14 0x7f06d185104d in QWidget::~QWidget() (/usr/lib/libQt5Widgets.so.5+0x19704d)
    #15 0x55bc01a40e25 in main ../main.cpp:27
    #16 0x7f06d0513151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
    #17 0x55bc01a40fed in _start (/home/alexandre/workspace/videolabs/vlc/doc/libvlc/QtGL/build/qtglvlc+0x5fed)

VLCVideo was not released, probably because it was considered like a
QObject (new VLCVideo(this)) and thus expected to be destroyed
automatically like a QObject.

Use a std::unique_ptr<> to destroy it when the parent widget is
destroyed.

Prince Gupta authored 4 years ago and Pierre Lamot committed 4 years ago

Signed-off-by: Pierre Lamot <pierre@videolabs.io>

Prince Gupta authored 4 years ago and Pierre Lamot committed 4 years ago

Signed-off-by: Pierre Lamot <pierre@videolabs.io>

Prince Gupta authored 4 years ago and Pierre Lamot committed 4 years ago

Signed-off-by: Pierre Lamot <pierre@videolabs.io>