Together with upstream, all those master fixes have been backported into the 2.1 branch.

I will be preparing an update package with the commits added

(actually interesting to see that 'updater' was the one chosen for this report: the updater is a win32 feature :) )

This is an autogenerated message for OBS integration:
This bug (914268) was mentioned in
https://build.opensuse.org/request/show/282450 Factory / vlc

a working update is prefered.

currently:

nothing provides pkgconfig(live555)

here is the complete cve allocation email.



    * Buffer overflow in updater:

    https://github.com/videolan/vlc/commit/fbe2837bc80f155c001781041a54c58b5524fc14


Use CVE-2014-9625 for this integer truncation caused by a cast to
size_t (with resultant buffer overflow).


    * Buffer overflow in mp4 demuxer:

    https://github.com/videolan/vlc/commit/2e7c7091a61aa5d07e7997b393d821e91f593c39


In 2e7c7091a61aa5d07e7997b393d821e91f593c39, the vendor discusses
"avoid an integer underflow" and "make sure no truncation occurs."
These are closely related to the original "If set to 7, the argument
passed to malloc at (1) is 0" report, but the vendor has explicitly
mentioned other attacks that were not directly covered in your
"Original Bug Reports" section.

Use CVE-2014-9626 for the integer underflow.

Use CVE-2014-9627 for the integer truncation on 32-bit platforms.

Use CVE-2014-9628 for the attacker-triggered zero-size malloc with
resultant buffer overflow.


    * Potential buffer overflow in Schroedinger Encoder

    https://github.com/videolan/vlc/commit/9bb0353a5c63a7f8c6fc853faa3df4b4df1f5eb5


Use CVE-2014-9629 for this integer overflow with resultant buffer
overflow.

    The function Encode in modules/codec/dirac.c

    The same code can be found in function Encode in
    modules/codec/schroedinger.c.

    * The potential buffer overflow in the Dirac Encoder was not fixed as
      the Dirac encoder no longer exists in the master branch.


The dirac.c and schroedinger.c issues have the same CVE ID because it
is exactly the same problem in an identical block of code. (In other
words, the code was copied from one to the other; there were not two
separate implementation errors.)


    * Invalid memory access in rtp code:

    https://github.com/videolan/vlc/commit/204291467724867b79735c0ee3aeb0dbc2200f97


Use CVE-2014-9630 for this stack allocation with an
attacker-controlled size.


    modules/services_discovery/sap.c:
    static sdp_t *ParseSDP

    char line[linelen + 1];


Use CVE-2015-1202 for this stack allocation with an
attacker-controlled size (we did not confirm this, but it appears that
the attacker would send an SAP multicast).

(

    The potential invalid writes in modules/services_discovery/sap.c and
    modules/access/ftp.c were not fixed


This is in contrast to the fixed rtp issue, in which an upcoming VLC
version would not be affected.

https://github.com/videolan/vlc/blob/master/modules/services_discovery/sap.c
suggests that this code is from 2004, which would mean that it affects
fewer old versions than -- for example -- ftp.c, which is a few years
older.
)


    modules/access/ftp.c:
    static int ftp_SendCommand

    char fmtbuf[fmtlen + 3];


Use CVE-2015-1203 for this stack allocation with an
attacker-controlled size (we did not confirm this, but it appears that
the attacker would operate an FTP server that includes long filenames
in an NLST response, and the victim would choose one of those files).


    We also found the following minor issues that we believe can at most
    result in a null-pointer dereference and thus, a crash. For the sake
    of completeness, we report them as well.

    The allocations at (1)-(6) in the function TrackCreateES in
    /modules/demux/mp4/mp4.c are not checked, possibly resulting in
    subsequent null-pointer dereferences when calling memcpy in the
    respective next line.

    In function EncoderSetAudioType in modules/codec/dmo/dmo.c, the
    allocation at (1) is not checked, possibly resulting a null-pointer
    dereference in the subsequent call to memcpy.

    * Null-pointer dereference in dmo codec:

    https://github.com/videolan/vlc/commit/229c385a79d48e41687fae8b4dfeaeef9c8c3eb7


There are currently no CVE IDs for these NULL pointer dereference
issues. Our understanding is that the common VLC use cases don't have
multiple sessions where the user is potentially working with valid
input and malicious input at exactly the same time. Accordingly, a
user can avoid the main impact by not accessing the malicious input
again. (Admittedly, there might be minor "data loss" if an unsaved
playlist is lost when VLC crashes, but we're not sure that a common
use case is to work with an unsaved playlist that is very difficult to
regenerate.)

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

openSUSE-SU-2015:0201-1: An update that fixes one vulnerability is now available.

Category: security (moderate)
Bug References: 914268
CVE References: CVE-2014-9625
Sources used:
openSUSE 13.2 (src):    live555-2014.09.22-4.4.1, vlc-2.1.5-2.4.1
openSUSE 13.1 (src):    live555-2014.09.22-2.4.1, vlc-2.1.5-14.1

released