sox debian package

sox debian package

[Jaromír Mikeš]

[-- Attachment #1.1: Type: text/plain, Size: 634 bytes --]

Hi sox devs,

I am thinking to adopt sox package in debian and maintain it in debian
pkg-multimedia team.
There are couple of bugs reported in debian against sox package.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=sox

Especially CVE bugs needs to be fixed

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878808
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878809
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878810
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870328

Please let me know if you can provide patches for these fixes
or make new release to fix these issues.

best regards

mira

[-- Attachment #1.2: Type: text/html, Size: 1569 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: sox debian package

[Eric Wong]

Jaromír Mikeš <mira.mikes@gmail.com> wrote:
> Please let me know if you can provide patches for these fixes
> or make new release to fix these issues.

Thanks for the email.  I guess neither Mans or I pay attention
to the bugtrackers :x, and the original developers are busy.
(and I don't like web-based UIs)

Anyways, I'll try to take a look at the CVEs this weekend or next
week, at latest.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: sox debian package

[Måns Rullgård]

Eric Wong <normalperson@yhbt.net> writes:

> Jaromír Mikeš <mira.mikes@gmail.com> wrote:
>> Please let me know if you can provide patches for these fixes
>> or make new release to fix these issues.
>
> Thanks for the email.  I guess neither Mans or I pay attention
> to the bugtrackers :x, and the original developers are busy.
> (and I don't like web-based UIs)
>
> Anyways, I'll try to take a look at the CVEs this weekend or next
> week, at latest.

I started looking at them today.  At least some of them seem easy to
fix.

-- 
Måns Rullgård

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: sox debian package

[Jaromír Mikeš]

[-- Attachment #1.1: Type: text/plain, Size: 812 bytes --]

2017-11-04 21:10 GMT+01:00 Måns Rullgård <mans@mansr.com>:

> Eric Wong <normalperson@yhbt.net> writes:
>
> > Jaromír Mikeš <mira.mikes@gmail.com> wrote:
> >> Please let me know if you can provide patches for these fixes
> >> or make new release to fix these issues.
> >
> > Thanks for the email.  I guess neither Mans or I pay attention
> > to the bugtrackers :x, and the original developers are busy.
> > (and I don't like web-based UIs)
> >
> > Anyways, I'll try to take a look at the CVEs this weekend or next
> > week, at latest.
>
> I started looking at them today.  At least some of them seem easy to
> fix.
>

​Thank you Eric and Mans for quick answer ... let me informed please about
progress.
Good to hear ​that at least some CVE are not difficult

best regards

mira

[-- Attachment #1.2: Type: text/html, Size: 1729 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: sox debian package

[Jaromír Mikeš]

[-- Attachment #1.1: Type: text/plain, Size: 1148 bytes --]

2017-11-04 21:43 GMT+01:00 Jaromír Mikeš <mira.mikes@gmail.com>:

>
>
> 2017-11-04 21:10 GMT+01:00 Måns Rullgård <mans@mansr.com>:
>
>> Eric Wong <normalperson@yhbt.net> writes:
>>
>> > Jaromír Mikeš <mira.mikes@gmail.com> wrote:
>> >> Please let me know if you can provide patches for these fixes
>> >> or make new release to fix these issues.
>> >
>> > Thanks for the email.  I guess neither Mans or I pay attention
>> > to the bugtrackers :x, and the original developers are busy.
>> > (and I don't like web-based UIs)
>> >
>> > Anyways, I'll try to take a look at the CVEs this weekend or next
>> > week, at latest.
>>
>> I started looking at them today.  At least some of them seem easy to
>> fix.
>>
>
> ​Thank you Eric and Mans for quick answer ... let me informed please about
> progress.
> Good to hear ​that at least some CVE are not difficult
>

​While I am playing a little bit with sox package debian spell checking
tool find some spelling errors in sox source code.
You might be interested apply attached patch upstream.
Hope attachments are allowed in mailing list

best regards

mira

[-- Attachment #1.2: Type: text/html, Size: 2665 bytes --]

[-- Attachment #2: 0003-spelling.patch --]
[-- Type: text/x-patch, Size: 6425 bytes --]

Index: sox/ChangeLog
===================================================================
--- sox.orig/ChangeLog
+++ sox/ChangeLog
@@ -916,7 +916,7 @@ sox-12.18.1	2006-05-07
 
   o The "filter" effect could go into infinite drain mode.  Now
     only drain 1 buffer.  noisered as well.
-  o SoX was ignoring user aborts (ctrl-c) if it occured during
+  o SoX was ignoring user aborts (ctrl-c) if it occurred during
     effect drain operations.  This was bad if effects had
     bugs and stuck in infinite loop.
   o Stop SoX from crashing when file type could not be auto
Index: sox/libsox.3
===================================================================
--- sox.orig/libsox.3
+++ sox/libsox.3
@@ -175,7 +175,7 @@ failures. Currently, relies on \fBsox_wa
 successfully read or written. If an error occurs, or the end-of-file
 is reached, the return value is a short item count or SOX_EOF. TODO:
 \fBsox_read\fR does not distiguish between end-of-file and error. Need
-an feof() and ferror() concept to determine which occured.
+an feof() and ferror() concept to determine which occurred.
 .P
 Upon successful completion \fBsox_close\fR returns 0. Otherwise, SOX_EOF
 is returned. In either case, any further access (including another
Index: sox/libsox.txt
===================================================================
--- sox.orig/libsox.txt
+++ sox/libsox.txt
@@ -148,7 +148,7 @@ RETURN VALUE
        or  written.  If  an  error  occurs, or the end-of-file is reached, the
        return value is a short item count or SOX_EOF. TODO: sox_read does  not
        distiguish  between  end-of-file and error. Need an feof() and ferror()
-       concept to determine which occured.
+       concept to determine which occurred.
 
        Upon successful completion sox_close returns 0. Otherwise,  SOX_EOF  is
        returned. In either case, any further access (including another call to
Index: sox/src/sox.c
===================================================================
--- sox.orig/src/sox.c
+++ sox/src/sox.c
@@ -1960,7 +1960,7 @@ static void usage(char const * message)
 "FORMAT OPTIONS (fopts):",
 "Input file format options need only be supplied for files that are headerless.",
 "Output files will have the same format as the input file where possible and not",
-"overriden by any of various means including providing output format options.",
+"overridden by any of various means including providing output format options.",
 "",
 "-v|--volume FACTOR       Input file volume adjustment factor (real number)",
 "--ignore-length          Ignore input file length given in header; read to EOF",
Index: sox/sox.1
===================================================================
--- sox.orig/sox.1
+++ sox/sox.1
@@ -880,7 +880,7 @@ If the \fB\-\-multi\-threaded\fR option
 will process audio channels for most multi-channel
 effects in parallel on hyper-threading/multi-core architectures. This
 may reduce processing time, though sometimes it may be necessary to use
-this option in conjuction with a larger buffer size than is the default
+this option in conjunction with a larger buffer size than is the default
 to gain any benefit from multi-threaded processing
 (e.g. 131072; see \fB\-\-buffer\fR above).
 .TP
@@ -3133,7 +3133,7 @@ effect (above):
 .EX
    rate 2k spectrogram \-X 200 \-Z \-10 \-w kaiser
 .EE
-Options are also avaliable to control the appearance (colour-set,
+Options are also available to control the appearance (colour-set,
 brightness, contrast, etc.) and filename of the spectrogram; e.g. with
 .EX
    sox my.wav \-n spectrogram \-m \-l \-o print.png
Index: sox/sox.txt
===================================================================
--- sox.orig/sox.txt
+++ sox/sox.txt
@@ -681,7 +681,7 @@ OPTIONS
               option is given however then SoX will process audio channels for
               most multi-channel effects in parallel on hyper-threading/multi-
               core  architectures.  This  may  reduce  processing time, though
-              sometimes it may be necessary to use this option  in  conjuction
+              sometimes it may be necessary to use this option  in conjunction
               with  a larger buffer size than is the default to gain any bene‐
               fit from multi-threaded processing (e.g.  131072;  see  --buffer
               above).
@@ -2366,7 +2366,7 @@ EFFECTS
               lar example, append the following to the `chime' command in  the
               description of the delay effect (above):
                  rate 2k spectrogram -X 200 -Z -10 -w kaiser
-              Options  are  also  avaliable to control the appearance (colour-
+              Options  are  also  available to control the appearance (colour-
               set, brightness, contrast, etc.) and filename  of  the  spectro‐
               gram; e.g. with
                  sox my.wav -n spectrogram -m -l -o print.png
Index: sox/src/fap.c
===================================================================
--- sox.orig/src/fap.c
+++ sox/src/fap.c
@@ -26,7 +26,7 @@ LSX_FORMAT_HANDLER(fap)
   static sox_format_handler_t handler;
   handler = *lsx_sndfile_format_fn();
   handler.description =
-    "Ensoniq PARIS digitial audio editing system (little endian)";
+    "Ensoniq PARIS digital audio editing system (little endian)";
   handler.names = names;
   handler.write_formats = write_encodings;
   return &handler;
Index: sox/src/paf.c
===================================================================
--- sox.orig/src/paf.c
+++ sox/src/paf.c
@@ -26,7 +26,7 @@ LSX_FORMAT_HANDLER(paf)
   static sox_format_handler_t handler;
   handler = *lsx_sndfile_format_fn();
   handler.description =
-    "Ensoniq PARIS digitial audio editing system (big endian)";
+    "Ensoniq PARIS digital audio editing system (big endian)";
   handler.names = names;
   handler.write_formats = write_encodings;
   return &handler;
Index: sox/src/oss.c
===================================================================
--- sox.orig/src/oss.c
+++ sox/src/oss.c
@@ -230,7 +230,7 @@ LSX_FORMAT_HANDLER(oss)
     SOX_ENCODING_UNSIGNED, 8, 0,
     0};
   static sox_format_handler_t const handler = {SOX_LIB_VERSION_CODE,
-    "Open Sound Sytem device driver for unix-like systems",
+    "Open Sound System device driver for unix-like systems",
     names, SOX_FILE_DEVICE,
     ossinit, lsx_rawread, lsx_rawstopread,
     ossinit, lsx_rawwrite, lsx_rawstopwrite,

[-- Attachment #3: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

[-- Attachment #4: Type: text/plain, Size: 158 bytes --]

_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: sox debian package

[Måns Rullgård]

Jaromír Mikeš <mira.mikes@gmail.com> writes:

> 2017-11-04 21:43 GMT+01:00 Jaromír Mikeš <mira.mikes@gmail.com>:
>
>>
>>
>> 2017-11-04 21:10 GMT+01:00 Måns Rullgård <mans@mansr.com>:
>>
>>> Eric Wong <normalperson@yhbt.net> writes:
>>>
>>> > Jaromír Mikeš <mira.mikes@gmail.com> wrote:
>>> >> Please let me know if you can provide patches for these fixes
>>> >> or make new release to fix these issues.
>>> >
>>> > Thanks for the email.  I guess neither Mans or I pay attention
>>> > to the bugtrackers :x, and the original developers are busy.
>>> > (and I don't like web-based UIs)
>>> >
>>> > Anyways, I'll try to take a look at the CVEs this weekend or next
>>> > week, at latest.
>>>
>>> I started looking at them today.  At least some of them seem easy to
>>> fix.
>>>
>>
>> ​Thank you Eric and Mans for quick answer ... let me informed please about
>> progress.
>> Good to hear ​that at least some CVE are not difficult
>>
>
> ​While I am playing a little bit with sox package debian spell checking
> tool find some spelling errors in sox source code.
> You might be interested apply attached patch upstream.
> Hope attachments are allowed in mailing list

Thanks.  Next time, however, please send git-formatted patches based on
the latest revision.  Some of the mistakes in your patch had already
been fixed.

-- 
Måns Rullgård

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: sox debian package

[Jaromír Mikeš]

[-- Attachment #1.1: Type: text/plain, Size: 1381 bytes --]

2017-11-05 13:32 GMT+01:00 Måns Rullgård <mans@mansr.com>:

> Jaromír Mikeš <mira.mikes@gmail.com> writes:
> >
> > ​While I am playing a little bit with sox package debian spell checking
> > tool find some spelling errors in sox source code.
> > You might be interested apply attached patch upstream.
> > Hope attachments are allowed in mailing list
>
> Thanks.  Next time, however, please send git-formatted patches based on
> the latest revision.  Some of the mistakes in your patch had already
> been fixed.
>

​Ohh yes ... sorry about that.
Now I updated to latest version ... but build failed due this error:

/bin/bash ../libtool --silent  --tag=CC  --silent --mode=link gcc
-Wtraditional-conversion  -g -O2 -fdebug-prefix-map=/build/sox-14.4.2=.
-fstack-protector-strong -Wformat -Werror=format-security -fstack-protector
-Wall -W -Wmissing-prototypes -Wstrict-prototypes -pedantic -fopenmp
-avoid-version -module -Wl,-z,relro -Wl,-z,defs -o libsox_fmt_gsm.la -rpath
/usr/lib/x86_64-linux-gnu/sox gsm.lo libsox.la  -lgsm -lm
.libs/flac.o: In function `decoder_read_callback':
./src/flac.c:63: undefined reference to `lsx_error'
collect2: error: ld returned 1 exit status
Makefile:1284: recipe for target 'libsox_fmt_flac.la' failed
make[3]: *** [libsox_fmt_flac.la] Error 1

Can you help me to fix it please?

best regards

mira​

[-- Attachment #1.2: Type: text/html, Size: 2501 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: sox debian package

[Måns Rullgård]

Jaromír Mikeš <mira.mikes@gmail.com> writes:

> 2017-11-05 13:32 GMT+01:00 Måns Rullgård <mans@mansr.com>:
>
>> Jaromír Mikeš <mira.mikes@gmail.com> writes:
>> >
>> > ​While I am playing a little bit with sox package debian spell checking
>> > tool find some spelling errors in sox source code.
>> > You might be interested apply attached patch upstream.
>> > Hope attachments are allowed in mailing list
>>
>> Thanks.  Next time, however, please send git-formatted patches based on
>> the latest revision.  Some of the mistakes in your patch had already
>> been fixed.
>>
>
> ​Ohh yes ... sorry about that.
> Now I updated to latest version ... but build failed due this error:
>
> /bin/bash ../libtool --silent  --tag=CC  --silent --mode=link gcc
> -Wtraditional-conversion  -g -O2 -fdebug-prefix-map=/build/sox-14.4.2=.
> -fstack-protector-strong -Wformat -Werror=format-security -fstack-protector
> -Wall -W -Wmissing-prototypes -Wstrict-prototypes -pedantic -fopenmp
> -avoid-version -module -Wl,-z,relro -Wl,-z,defs -o libsox_fmt_gsm.la -rpath
> /usr/lib/x86_64-linux-gnu/sox gsm.lo libsox.la  -lgsm -lm
> .libs/flac.o: In function `decoder_read_callback':
> ./src/flac.c:63: undefined reference to `lsx_error'
> collect2: error: ld returned 1 exit status
> Makefile:1284: recipe for target 'libsox_fmt_flac.la' failed
> make[3]: *** [libsox_fmt_flac.la] Error 1
>
> Can you help me to fix it please?

https://github.com/mansr/sox/commit/600c291ab00f4afb2941cd93f69942fe395f3e8a

-- 
Måns Rullgård

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: sox debian package

[Måns Rullgård]

Jaromír Mikeš <mira.mikes@gmail.com> writes:

> Hi sox devs,
>
> I am thinking to adopt sox package in debian and maintain it in debian
> pkg-multimedia team.
> There are couple of bugs reported in debian against sox package.
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=sox
>
> Especially CVE bugs needs to be fixed
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878808
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878809
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878810
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870328
>
> Please let me know if you can provide patches for these fixes
> or make new release to fix these issues.

All but one fixed here: https://github.com/mansr/sox

-- 
Måns Rullgård

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: sox debian package

[Jaromír Mikeš]

[-- Attachment #1.1: Type: text/plain, Size: 1023 bytes --]

2017-11-05 18:12 GMT+01:00 Måns Rullgård <mans@mansr.com>:

> Jaromír Mikeš <mira.mikes@gmail.com> writes:
>
> > Hi sox devs,
> >
> > I am thinking to adopt sox package in debian and maintain it in debian
> > pkg-multimedia team.
> > There are couple of bugs reported in debian against sox package.
> >
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=sox
> >
> > Especially CVE bugs needs to be fixed
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878808
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878809
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878810
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870328
> >
> > Please let me know if you can provide patches for these fixes
> > or make new release to fix these issues.
>
> All but one fixed here: https://github.com/mansr/sox
>

​Thank you ... you are super quick!
There is one more spelling fix in 0.14.2 release in src/wav.c see attached
file

best regards

mira​

[-- Attachment #1.2: Type: text/html, Size: 2631 bytes --]

[-- Attachment #2: 0003-spelling.patch --]
[-- Type: text/x-patch, Size: 3575 bytes --]

Description: spelling fixes
Author: Jaromír Mikeš <mira.mikes@seznam.cz>
Forwarded: sox-devel@lists.sourceforge.net

Index: sox/ChangeLog
===================================================================
--- sox.orig/ChangeLog
+++ sox/ChangeLog
@@ -972,7 +972,7 @@ sox-12.18.1	2006-05-07
 
   o The "filter" effect could go into infinite drain mode.  Now
     only drain 1 buffer.  noisered as well.
-  o SoX was ignoring user aborts (ctrl-c) if it occured during
+  o SoX was ignoring user aborts (ctrl-c) if it occurred during
     effect drain operations.  This was bad if effects had
     bugs and stuck in infinite loop.
   o Stop SoX from crashing when file type could not be auto
Index: sox/libsox.3
===================================================================
--- sox.orig/libsox.3
+++ sox/libsox.3
@@ -175,7 +175,7 @@ failures. Currently, relies on \fBsox_wa
 successfully read or written. If an error occurs, or the end-of-file
 is reached, the return value is a short item count or SOX_EOF. TODO:
 \fBsox_read\fR does not distiguish between end-of-file and error. Need
-an feof() and ferror() concept to determine which occured.
+an feof() and ferror() concept to determine which occurred.
 .P
 Upon successful completion \fBsox_close\fR returns 0. Otherwise, SOX_EOF
 is returned. In either case, any further access (including another
Index: sox/libsox.txt
===================================================================
--- sox.orig/libsox.txt
+++ sox/libsox.txt
@@ -148,7 +148,7 @@ RETURN VALUE
        or  written.  If  an  error  occurs, or the end-of-file is reached, the
        return value is a short item count or SOX_EOF. TODO: sox_read does  not
        distiguish  between  end-of-file and error. Need an feof() and ferror()
-       concept to determine which occured.
+       concept to determine which occurred.
 
        Upon successful completion sox_close returns 0. Otherwise,  SOX_EOF  is
        returned. In either case, any further access (including another call to
Index: sox/src/fap.c
===================================================================
--- sox.orig/src/fap.c
+++ sox/src/fap.c
@@ -26,7 +26,7 @@ LSX_FORMAT_HANDLER(fap)
   static sox_format_handler_t handler;
   handler = *lsx_sndfile_format_fn();
   handler.description =
-    "Ensoniq PARIS digitial audio editing system (little endian)";
+    "Ensoniq PARIS digital audio editing system (little endian)";
   handler.names = names;
   handler.write_formats = write_encodings;
   return &handler;
Index: sox/src/paf.c
===================================================================
--- sox.orig/src/paf.c
+++ sox/src/paf.c
@@ -26,7 +26,7 @@ LSX_FORMAT_HANDLER(paf)
   static sox_format_handler_t handler;
   handler = *lsx_sndfile_format_fn();
   handler.description =
-    "Ensoniq PARIS digitial audio editing system (big endian)";
+    "Ensoniq PARIS digital audio editing system (big endian)";
   handler.names = names;
   handler.write_formats = write_encodings;
   return &handler;
Index: sox/src/wav.c
===================================================================
--- sox.orig/src/wav.c
+++ sox/src/wav.c
@@ -442,7 +442,7 @@ static int findChunk(sox_format_t * ft,
             }
             else
             {
-                lsx_fail_errno(ft, SOX_EHDR, "Cannot yet read block sizes of arbitary RF64 chunks, cannot find chunk '%s'", Label);
+                lsx_fail_errno(ft, SOX_EHDR, "Cannot yet read block sizes of arbitrary RF64 chunks, cannot find chunk '%s'", Label);
                 return SOX_EOF;
             }
         }

[-- Attachment #3: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

[-- Attachment #4: Type: text/plain, Size: 158 bytes --]

_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: sox debian package

[Jaromír Mikeš]

[-- Attachment #1.1: Type: text/plain, Size: 1442 bytes --]

2017-11-05 18:19 GMT+01:00 Jaromír Mikeš <mira.mikes@gmail.com>:

>
>
> 2017-11-05 18:12 GMT+01:00 Måns Rullgård <mans@mansr.com>:
>
>> Jaromír Mikeš <mira.mikes@gmail.com> writes:
>>
>> > Hi sox devs,
>> >
>> > I am thinking to adopt sox package in debian and maintain it in debian
>> > pkg-multimedia team.
>> > There are couple of bugs reported in debian against sox package.
>> >
>> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=sox
>> >
>> > Especially CVE bugs needs to be fixed
>> >
>> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878808
>> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878809
>> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878810
>> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870328
>> >
>> > Please let me know if you can provide patches for these fixes
>> > or make new release to fix these issues.
>>
>> All but one fixed here: https://github.com/mansr/sox
>>
>
​Mans I have a question about ​
 lpc10
​ we ​have this lib in debian so I would rather build sox against system
wide lib than embedded.
But when add it as build dependency it is still marked as embedded during
configuration.
lpc10......................dyn (in-tree)
Similar about opus I am building with libopus-dev installed but I see this
opus.......................no

And what about ffmpeg? it is not needed any more?

best regards

mira

[-- Attachment #1.2: Type: text/html, Size: 3626 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

[PATCH] adpcm: fix stack overflow (CVE-2017-15372)

[Eric Wong]

Måns Rullgård <mans@mansr.com> wrote:
> All but one fixed here: https://github.com/mansr/sox

I think this should fix the last one.  I didn't check too
closely, just verified it's no longer segfaulting.

(But lsx_valloc doesn't check for multiplication overflow)

-----------8<---------
From: Eric Wong <e@80x24.org>
Subject: [PATCH] adpcm: fix stack overflow (CVE-2017-15372)

---
 src/adpcm.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/adpcm.c b/src/adpcm.c
index 2e13867e..e921eaba 100644
--- a/src/adpcm.c
+++ b/src/adpcm.c
@@ -113,7 +113,10 @@ const char *lsx_ms_adpcm_block_expand_i(
   const unsigned char *ip;
   unsigned ch;
   const char *errmsg = NULL;
-  MsState_t state[4];  /* One decompressor state for each channel */
+  MsState_t *state;
+
+  /* One decompressor state for each channel */
+  lsx_valloc(state, chans);
 
   /* Read the four-byte header for each channel */
   ip = ibuff;
-- 
EW

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH] adpcm: fix stack overflow (CVE-2017-15372)

[Måns Rullgård]

Eric Wong <normalperson@yhbt.net> writes:

> Måns Rullgård <mans@mansr.com> wrote:
>> All but one fixed here: https://github.com/mansr/sox
>
> I think this should fix the last one.  I didn't check too
> closely, just verified it's no longer segfaulting.
>
> (But lsx_valloc doesn't check for multiplication overflow)
>
> -----------8<---------
> From: Eric Wong <e@80x24.org>
> Subject: [PATCH] adpcm: fix stack overflow (CVE-2017-15372)
>
> ---
>  src/adpcm.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/adpcm.c b/src/adpcm.c
> index 2e13867e..e921eaba 100644
> --- a/src/adpcm.c
> +++ b/src/adpcm.c
> @@ -113,7 +113,10 @@ const char *lsx_ms_adpcm_block_expand_i(
>    const unsigned char *ip;
>    unsigned ch;
>    const char *errmsg = NULL;
> -  MsState_t state[4];  /* One decompressor state for each channel */
> +  MsState_t *state;
> +
> +  /* One decompressor state for each channel */
> +  lsx_valloc(state, chans);
>
>    /* Read the four-byte header for each channel */
>    ip = ibuff;

This will leak memory like crazy.

I'd prefer not to do a malloc/free for each block, but rather do it just
once.  This will require a little more work, of course.

-- 
Måns Rullgård

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [PATCH] adpcm: fix stack overflow (CVE-2017-15372)

[Jaromír Mikeš]

[-- Attachment #1.1: Type: text/plain, Size: 1656 bytes --]

2017-11-07 10:26 GMT+01:00 Måns Rullgård <mans@mansr.com>:

> Eric Wong <normalperson@yhbt.net> writes:
>
> > Måns Rullgård <mans@mansr.com> wrote:
> >> All but one fixed here: https://github.com/mansr/sox
> >
> > I think this should fix the last one.  I didn't check too
> > closely, just verified it's no longer segfaulting.
> >
> > (But lsx_valloc doesn't check for multiplication overflow)
> >
> > -----------8<---------
> > From: Eric Wong <e@80x24.org>
> > Subject: [PATCH] adpcm: fix stack overflow (CVE-2017-15372)
> >
> > ---
> >  src/adpcm.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/adpcm.c b/src/adpcm.c
> > index 2e13867e..e921eaba 100644
> > --- a/src/adpcm.c
> > +++ b/src/adpcm.c
> > @@ -113,7 +113,10 @@ const char *lsx_ms_adpcm_block_expand_i(
> >    const unsigned char *ip;
> >    unsigned ch;
> >    const char *errmsg = NULL;
> > -  MsState_t state[4];  /* One decompressor state for each channel */
> > +  MsState_t *state;
> > +
> > +  /* One decompressor state for each channel */
> > +  lsx_valloc(state, chans);
> >
> >    /* Read the four-byte header for each channel */
> >    ip = ibuff;
>
> This will leak memory like crazy.
>
> I'd prefer not to do a malloc/free for each block, but rather do it just
> once.  This will require a little more work, of course.
>

​Hi,

good to know I will wait for better fix then.
BTW I moved debian packaging here if you are interested:
https://anonscm.debian.org/git/pkg-multimedia/sox.git​


​I think it is better than do it in sourceforge upstream repo.

best regrads

mira​

[-- Attachment #1.2: Type: text/html, Size: 3173 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH] adpcm: fix stack overflow (CVE-2017-15372)

[Måns Rullgård]

Jaromír Mikeš <mira.mikes@gmail.com> writes:

> BTW I moved debian packaging here if you are interested:
> https://anonscm.debian.org/git/pkg-multimedia/sox.git​
>
> ​I think it is better than do it in sourceforge upstream repo.

Yes, that's better handled separately by each distro.

-- 
Måns Rullgård

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH] adpcm: fix stack overflow (CVE-2017-15372)

[Eric Wong]

Måns Rullgård <mans@mansr.com> wrote:
> This will leak memory like crazy.

You're right. I somehow got spoiled into thinking it was
alloca-like from another project :x.

> I'd prefer not to do a malloc/free for each block, but rather do it just
> once.  This will require a little more work, of course.

Yes, it should be in the per-stream private data.  Will work on
it later today if you're busy.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH] adpcm: fix stack overflow (CVE-2017-15372)

[Måns Rullgård]

Eric Wong <normalperson@yhbt.net> writes:

> Måns Rullgård <mans@mansr.com> wrote:
>> This will leak memory like crazy.
>
> You're right. I somehow got spoiled into thinking it was
> alloca-like from another project :x.

Never use such functions.  They are dangerous.

>> I'd prefer not to do a malloc/free for each block, but rather do it just
>> once.  This will require a little more work, of course.
>
> Yes, it should be in the per-stream private data.  Will work on
> it later today if you're busy.

OK, I'll leave it to you then.

-- 
Måns Rullgård

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [PATCH] adpcm: fix stack overflow (CVE-2017-15372)

[Eric Wong]

Måns Rullgård <mans@mansr.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> 
> > Måns Rullgård <mans@mansr.com> wrote:
> >> This will leak memory like crazy.
> >
> > You're right. I somehow got spoiled into thinking it was
> > alloca-like from another project :x.
> 
> Never use such functions.  They are dangerous.

If it were alloca-only, yes.  The macro I was thinking of relied
on GC for larger allocations; and only used alloca for small ones.

> >> I'd prefer not to do a malloc/free for each block, but rather do it just
> >> once.  This will require a little more work, of course.
> >
> > Yes, it should be in the per-stream private data.  Will work on
> > it later today if you're busy.
> 
> OK, I'll leave it to you then.

So I didn't want to mess with the lsx_ms_adpcm_block_expand_i
signature for now.  I've made it use alloca for <= 1024 uses
and it'll only use the slow malloc+free path for the rare
128+ channel audio files.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

[PATCH v2] adpcm: fix stack overflow (CVE-2017-15372)

[Eric Wong]

---
 src/adpcm.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/adpcm.c b/src/adpcm.c
index 2e13867e..b400eb95 100644
--- a/src/adpcm.c
+++ b/src/adpcm.c
@@ -113,7 +113,13 @@ const char *lsx_ms_adpcm_block_expand_i(
   const unsigned char *ip;
   unsigned ch;
   const char *errmsg = NULL;
-  MsState_t state[4];  /* One decompressor state for each channel */
+
+  /* One decompressor state for each channel */
+  MsState_t *state;
+  size_t size = sizeof(*state) * chans;
+  const size_t alloca_max = 1024;
+
+  state = size > alloca_max ? lsx_malloc(size) : alloca(size);
 
   /* Read the four-byte header for each channel */
   ip = ibuff;
@@ -158,6 +164,10 @@ const char *lsx_ms_adpcm_block_expand_i(
       if (++ch2 == chans) ch2 = 0;
     }
   }
+
+  if (size > alloca_max)
+    free(state);
+
   return errmsg;
 }
 
-- 
EW

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH v2] adpcm: fix stack overflow (CVE-2017-15372)

[Hans Petter Selasky]

On 11/08/17 00:38, Eric Wong wrote:
> @@ -113,7 +113,13 @@ const char *lsx_ms_adpcm_block_expand_i(
>     const unsigned char *ip;
>     unsigned ch;
>     const char *errmsg = NULL;
> -  MsState_t state[4];  /* One decompressor state for each channel */
> +
> +  /* One decompressor state for each channel */
> +  MsState_t *state;
> +  size_t size = sizeof(*state) * chans;
> +  const size_t alloca_max = 1024;
> +

Hi,

Just make a fixed buffer on the stack instead of using alloca().

> +  state = size > alloca_max ? lsx_malloc(size) : alloca(size);
>   
>     /* Read the four-byte header for each channel */
>     ip = ibuff;
> @@ -158,6 +164,10 @@ const char *lsx_ms_adpcm_block_expand_i(
>         if (++ch2 == chans) ch2 = 0;
>       }
>     }
> +
> +  if (size > alloca_max)
> +    free(state);
> +
>     return errmsg;
>   }

Is the "chans" argument range-checked anywhere? You should put a limit 
how many channels are supported!

--HPS

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH v2] adpcm: fix stack overflow (CVE-2017-15372)

[Måns Rullgård]

Hans Petter Selasky <hps@selasky.org> writes:

> On 11/08/17 00:38, Eric Wong wrote:
>> @@ -113,7 +113,13 @@ const char *lsx_ms_adpcm_block_expand_i(
>>     const unsigned char *ip;
>>     unsigned ch;
>>     const char *errmsg = NULL;
>> -  MsState_t state[4];  /* One decompressor state for each channel */
>> +
>> +  /* One decompressor state for each channel */
>> +  MsState_t *state;
>> +  size_t size = sizeof(*state) * chans;
>> +  const size_t alloca_max = 1024;
>> +
>
> Hi,
>
> Just make a fixed buffer on the stack instead of using alloca().
>
>> +  state = size > alloca_max ? lsx_malloc(size) : alloca(size);
>>       /* Read the four-byte header for each channel */
>>     ip = ibuff;
>> @@ -158,6 +164,10 @@ const char *lsx_ms_adpcm_block_expand_i(
>>         if (++ch2 == chans) ch2 = 0;
>>       }
>>     }
>> +
>> +  if (size > alloca_max)
>> +    free(state);
>> +
>>     return errmsg;
>>   }
>
> Is the "chans" argument range-checked anywhere? You should put a limit
> how many channels are supported!

The WAV container is limited to 64k channels.  We could of course
enforce a lower limit.

-- 
Måns Rullgård

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH v2] adpcm: fix stack overflow (CVE-2017-15372)

[Hans Petter Selasky]

On 11/08/17 12:07, Måns Rullgård wrote:
> The WAV container is limited to 64k channels.  We could of course
> enforce a lower limit.

Hi,

You should not allow that many channels. Make sure the value is >= 1, to 
avoid division by zero and <= 512 to avoid overflow. During my time as a 
sound technican, it is very rare that the number of channels go beyond 
64. It has practical implications, that the data rate goes into the roof 
and USB audio among others is not possible.

--HPS

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH v2] adpcm: fix stack overflow (CVE-2017-15372)

[Måns Rullgård]

Hans Petter Selasky <hps@selasky.org> writes:

> On 11/08/17 12:07, Måns Rullgård wrote:
>> The WAV container is limited to 64k channels.  We could of course
>> enforce a lower limit.
>
> Hi,
>
> You should not allow that many channels. Make sure the value is >= 1, to
> avoid division by zero

We already do that.

> and <= 512 to avoid overflow.

That's a pretty arbitrary limit.

> During my time as a sound technican, it is very rare that the number
> of channels go beyond 64. It has practical implications, that the data
> rate goes into the roof and USB audio among others is not possible.

During my time working on AV software, there's no end to the crazy
things I've seen people do.  Someone might have a good reason to store a
silly number of channels.  Not all audio files are intended to be sent
to a playback device.

-- 
Måns Rullgård

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH] adpcm: fix stack overflow (CVE-2017-15372)

[Måns Rullgård]

Eric Wong <normalperson@yhbt.net> writes:

> Måns Rullgård <mans@mansr.com> wrote:
>> Eric Wong <normalperson@yhbt.net> writes:
>> 
>> > Måns Rullgård <mans@mansr.com> wrote:
>> >> This will leak memory like crazy.
>> >
>> > You're right. I somehow got spoiled into thinking it was
>> > alloca-like from another project :x.
>> 
>> Never use such functions.  They are dangerous.
>
> If it were alloca-only, yes.  The macro I was thinking of relied
> on GC for larger allocations; and only used alloca for small ones.
>
>> >> I'd prefer not to do a malloc/free for each block, but rather do it just
>> >> once.  This will require a little more work, of course.
>> >
>> > Yes, it should be in the per-stream private data.  Will work on
>> > it later today if you're busy.
>> 
>> OK, I'll leave it to you then.
>
> So I didn't want to mess with the lsx_ms_adpcm_block_expand_i
> signature for now.  I've made it use alloca for <= 1024 uses
> and it'll only use the slow malloc+free path for the rare
> 128+ channel audio files.

I really don't want to use alloca().  It is non-standard, non-portable,
somewhat dangerous, and messes with compiler optimisation.  There is
nothing good about it.  Guess I'll have to do it myself.

-- 
Måns Rullgård

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH] adpcm: fix stack overflow (CVE-2017-15372)

[Eric Wong]

Måns Rullgård <mans@mansr.com> wrote:
> I really don't want to use alloca().  It is non-standard, non-portable,
> somewhat dangerous, and messes with compiler optimisation.  There is
> nothing good about it.  Guess I'll have to do it myself.

One could also use thread-specific data to avoid messing with the
signature.  I don't know if that's too much churn and don't care
that much as long as the problem is fixed.

Thanks.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH] adpcm: fix stack overflow (CVE-2017-15372)

[Måns Rullgård]

Eric Wong <normalperson@yhbt.net> writes:

F> Måns Rullgård <mans@mansr.com> wrote:
>> I really don't want to use alloca().  It is non-standard, non-portable,
>> somewhat dangerous, and messes with compiler optimisation.  There is
>> nothing good about it.  Guess I'll have to do it myself.
>
> One could also use thread-specific data to avoid messing with the
> signature.  I don't know if that's too much churn and don't care
> that much as long as the problem is fixed.

I'll fix it.

-- 
Måns Rullgård

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

[PATCH] adpcm: fix stack overflow with >4 channels (CVE-2017-15372)

[Mans Rullgard]

---
 src/adpcm.c | 8 +++++++-
 src/adpcm.h | 3 +++
 src/wav.c   | 5 ++++-
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/src/adpcm.c b/src/adpcm.c
index 2e13867e94b0..f64b7d5c2787 100644
--- a/src/adpcm.c
+++ b/src/adpcm.c
@@ -71,6 +71,11 @@ const short lsx_ms_adpcm_i_coef[7][2] = {
                         { 392,-232}
 };
 
+extern void *lsx_ms_adpcm_alloc(unsigned chans)
+{
+        return lsx_malloc(chans * sizeof(MsState_t));
+}
+
 static inline sox_sample_t AdpcmDecode(sox_sample_t c, MsState_t *state,
                                sox_sample_t sample1, sox_sample_t sample2)
 {
@@ -102,6 +107,7 @@ static inline sox_sample_t AdpcmDecode(sox_sample_t c, MsState_t *state,
 
 /* lsx_ms_adpcm_block_expand_i() outputs interleaved samples into one output buffer */
 const char *lsx_ms_adpcm_block_expand_i(
+        void *priv,
         unsigned chans,          /* total channels             */
         int nCoef,
         const short *coef,
@@ -113,7 +119,7 @@ const char *lsx_ms_adpcm_block_expand_i(
   const unsigned char *ip;
   unsigned ch;
   const char *errmsg = NULL;
-  MsState_t state[4];  /* One decompressor state for each channel */
+  MsState_t *state = priv;  /* One decompressor state for each channel */
 
   /* Read the four-byte header for each channel */
   ip = ibuff;
diff --git a/src/adpcm.h b/src/adpcm.h
index af4d6f08117d..db5cc6152196 100644
--- a/src/adpcm.h
+++ b/src/adpcm.h
@@ -29,8 +29,11 @@
 /* default coef sets */
 extern const short lsx_ms_adpcm_i_coef[7][2];
 
+extern void *lsx_ms_adpcm_alloc(unsigned chans);
+
 /* lsx_ms_adpcm_block_expand_i() outputs interleaved samples into one output buffer */
 extern const char *lsx_ms_adpcm_block_expand_i(
+	void *priv,
 	unsigned chans,          /* total channels             */
 	int nCoef,
 	const short *coef,
diff --git a/src/wav.c b/src/wav.c
index fad334cf56e9..066be6d7732d 100644
--- a/src/wav.c
+++ b/src/wav.c
@@ -82,6 +82,7 @@ typedef struct {
     /* following used by *ADPCM wav files */
     unsigned short nCoefs;          /* ADPCM: number of coef sets */
     short         *lsx_ms_adpcm_i_coefs;          /* ADPCM: coef sets           */
+    void          *ms_adpcm_data;   /* Private data of adpcm decoder */
     unsigned char *packet;          /* Temporary buffer for packets */
     short         *samples;         /* interleaved samples buffer */
     short         *samplePtr;       /* Pointer to current sample  */
@@ -175,7 +176,7 @@ static unsigned short  AdpcmReadBlock(sox_format_t * ft)
         }
     }
 
-    errmsg = lsx_ms_adpcm_block_expand_i(ft->signal.channels, wav->nCoefs, wav->lsx_ms_adpcm_i_coefs, wav->packet, wav->samples, samplesThisBlock);
+    errmsg = lsx_ms_adpcm_block_expand_i(wav->ms_adpcm_data, ft->signal.channels, wav->nCoefs, wav->lsx_ms_adpcm_i_coefs, wav->packet, wav->samples, samplesThisBlock);
 
     if (errmsg)
         lsx_warn("%s", errmsg);
@@ -791,6 +792,7 @@ static int startread(sox_format_t * ft)
 
         /* nCoefs, lsx_ms_adpcm_i_coefs used by adpcm.c */
         wav->lsx_ms_adpcm_i_coefs = lsx_malloc(wav->nCoefs * 2 * sizeof(short));
+        wav->ms_adpcm_data = lsx_ms_adpcm_alloc(wChannels);
         {
             int i, errct=0;
             for (i=0; len>=2 && i < 2*wav->nCoefs; i++) {
@@ -1216,6 +1218,7 @@ static int stopread(sox_format_t * ft)
     free(wav->packet);
     free(wav->samples);
     free(wav->lsx_ms_adpcm_i_coefs);
+    free(wav->ms_adpcm_data);
     free(wav->comment);
     wav->comment = NULL;
 
-- 
2.15.0


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH] adpcm: fix stack overflow with >4 channels (CVE-2017-15372)

[Eric Wong]

Mans Rullgard <mans@mansr.com> wrote:
> --- a/src/adpcm.h
> +++ b/src/adpcm.h
> @@ -29,8 +29,11 @@
>  /* default coef sets */
>  extern const short lsx_ms_adpcm_i_coef[7][2];
>  
> +extern void *lsx_ms_adpcm_alloc(unsigned chans);
> +
>  /* lsx_ms_adpcm_block_expand_i() outputs interleaved samples into one output buffer */
>  extern const char *lsx_ms_adpcm_block_expand_i(
> +	void *priv,
>  	unsigned chans,          /* total channels             */
>  	int nCoef,
>  	const short *coef,

Thanks, seems fine; though I'd probably export an opaque struct
which makes the unsigned chans arg redundant.

I'm a little concerned about the internal API changes like this
affecting some 3rd-party code somewhere; but I guess we limit
our exports nowadays (ugh, and that export regexp is nasty)

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH] adpcm: fix stack overflow with >4 channels (CVE-2017-15372)

[Måns Rullgård]

Eric Wong <normalperson@yhbt.net> writes:

> Mans Rullgard <mans@mansr.com> wrote:
>> --- a/src/adpcm.h
>> +++ b/src/adpcm.h
>> @@ -29,8 +29,11 @@
>>  /* default coef sets */
>>  extern const short lsx_ms_adpcm_i_coef[7][2];
>>  
>> +extern void *lsx_ms_adpcm_alloc(unsigned chans);
>> +
>>  /* lsx_ms_adpcm_block_expand_i() outputs interleaved samples into one output buffer */
>>  extern const char *lsx_ms_adpcm_block_expand_i(
>> +	void *priv,
>>  	unsigned chans,          /* total channels             */
>>  	int nCoef,
>>  	const short *coef,
>
> Thanks, seems fine; though I'd probably export an opaque struct
> which makes the unsigned chans arg redundant.

Do you mean to store the number of channels as well as the state buffer
in a struct?

> I'm a little concerned about the internal API changes like this
> affecting some 3rd-party code somewhere; but I guess we limit
> our exports nowadays (ugh, and that export regexp is nasty)

These functions aren't exported, and the supported interface is whatever
is in sox.h, nothing else.

-- 
Måns Rullgård

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH] adpcm: fix stack overflow with >4 channels (CVE-2017-15372)

[Eric Wong]

Måns Rullgård <mans@mansr.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> > Mans Rullgard <mans@mansr.com> wrote:
> >> --- a/src/adpcm.h
> >> +++ b/src/adpcm.h
> >> @@ -29,8 +29,11 @@
> >>  /* default coef sets */
> >>  extern const short lsx_ms_adpcm_i_coef[7][2];
> >>  
> >> +extern void *lsx_ms_adpcm_alloc(unsigned chans);
> >> +
> >>  /* lsx_ms_adpcm_block_expand_i() outputs interleaved samples into one output buffer */
> >>  extern const char *lsx_ms_adpcm_block_expand_i(
> >> +	void *priv,
> >>  	unsigned chans,          /* total channels             */
> >>  	int nCoef,
> >>  	const short *coef,
> >
> > Thanks, seems fine; though I'd probably export an opaque struct
> > which makes the unsigned chans arg redundant.
> 
> Do you mean to store the number of channels as well as the state buffer
> in a struct?

Exactly.

> > I'm a little concerned about the internal API changes like this
> > affecting some 3rd-party code somewhere; but I guess we limit
> > our exports nowadays (ugh, and that export regexp is nasty)
> 
> These functions aren't exported, and the supported interface is whatever
> is in sox.h, nothing else.

OK.  I guess I'm overly cautious from other projects where
people reach deep into internals and rely on it :/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [PATCH] adpcm: fix stack overflow with >4 channels (CVE-2017-15372)

[Måns Rullgård]

Eric Wong <normalperson@yhbt.net> writes:

> Måns Rullgård <mans@mansr.com> wrote:
>> Eric Wong <normalperson@yhbt.net> writes:
>> > Mans Rullgard <mans@mansr.com> wrote:
>> >> --- a/src/adpcm.h
>> >> +++ b/src/adpcm.h
>> >> @@ -29,8 +29,11 @@
>> >>  /* default coef sets */
>> >>  extern const short lsx_ms_adpcm_i_coef[7][2];
>> >>  
>> >> +extern void *lsx_ms_adpcm_alloc(unsigned chans);
>> >> +
>> >>  /* lsx_ms_adpcm_block_expand_i() outputs interleaved samples into one output buffer */
>> >>  extern const char *lsx_ms_adpcm_block_expand_i(
>> >> +	void *priv,
>> >>  	unsigned chans,          /* total channels             */
>> >>  	int nCoef,
>> >>  	const short *coef,
>> >
>> > Thanks, seems fine; though I'd probably export an opaque struct
>> > which makes the unsigned chans arg redundant.
>> 
>> Do you mean to store the number of channels as well as the state buffer
>> in a struct?
>
> Exactly.

Sure, we could do that.  Then we could put some other stuff there too.

>> > I'm a little concerned about the internal API changes like this
>> > affecting some 3rd-party code somewhere; but I guess we limit
>> > our exports nowadays (ugh, and that export regexp is nasty)
>> 
>> These functions aren't exported, and the supported interface is
>> whatever is in sox.h, nothing else.
>
> OK.  I guess I'm overly cautious from other projects where
> people reach deep into internals and rely on it :/

My opinion is that if you rely on internal, undocumented interfaces
exposed by accident, you're on your own and should expect breakage from
time to time.

-- 
Måns Rullgård

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel