Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

a div zero vul in function double64_init() in libsndfile-1.0.28 #318

Closed
Xin-Jiang opened this issue Sep 14, 2017 · 3 comments
Closed

a div zero vul in function double64_init() in libsndfile-1.0.28 #318

Xin-Jiang opened this issue Sep 14, 2017 · 3 comments

Comments

@Xin-Jiang
Copy link 

╭─root@linux-jiangxin in /home/jiangxin/experiment/fuzz/AFL/target/libsndfile-1.0.28/fuzz 
╰$gdb ../programs/sndfile-play
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources o
[crash-div0.zip](https://github.com/erikd/libsndfile/files/1302481/crash-div0.zip)

nline at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../programs/sndfile-play...done.
(gdb) run out-all/Master/crashes/id:000000,sig:08,src:001431,op:int32,pos:232,val:be:+32
Starting program: /home/jiangxin/experiment/fuzz/AFL/target/libsndfile-1.0.28/programs/sndfile-play out-all/Master/crashes/id:000000,sig:08,src:001431,op:int32,pos:232,val:be:+32
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Playing out-all/Master/crashes/id:000000,sig:08,src:001431,op:int32,pos:232,val:be:+32

Program received signal SIGFPE, Arithmetic exception.
0x00000000004f6e6d in double64_init (psf=psf@entry=0x801010) at double64.c:252
252		psf->sf.frames = psf->datalength / psf->blockwidth ;
(gdb) bt
#0  0x00000000004f6e6d in double64_init (psf=psf@entry=0x801010) at double64.c:252
#1  0x000000000044e9ce in mat5_open (psf=psf@entry=0x801010) at mat5.c:131
#2  0x0000000000424c58 in psf_open_file (psf=0x801010, sfinfo=0x7fffffffdf90) at sndfile.c:3137
#3  0x0000000000403495 in alsa_play (argv=<optimized out>, argc=<optimized out>) at sndfile-play.c:104
#4  main (argc=<optimized out>, argv=<optimized out>) at sndfile-play.c:841
(gdb) p psf->blockwidth
$1 = 0
(gdb)
@Xin-Jiang
Copy link
Author

crash-div0.zip

@fgeek
Copy link

fgeek commented Sep 21, 2017

https://nvd.nist.gov/vuln/detail/CVE-2017-14634

fabiangreffrath added a commit to fabiangreffrath/libsndfile that referenced this issue Sep 28, 2017
@fabiangreffrath
double64_init: force psf->sf.channels in a reasonable range
904c515 
This prevents division by zero later in the code.

While the trivial case to catch this (i.e. sf.channels < 1) has already
been covered, a crafted file may report a number of channels that is
so high (i.e. > INT_MAX/sizeof(double)) that it "somehow" gets
miscalculated to zero (if this makes sense) in the determination of the
blockwidth. Since we only support a limited number of channels anyway,
make sure to check here as well.

Fixes libsndfile#318
CVE-2017-14634
@fabiangreffrath fabiangreffrath mentioned this issue Sep 28, 2017
Closed
@erikd erikd closed this as completed Sep 30, 2017
erikd pushed a commit that referenced this issue Sep 30, 2017
@fabiangreffrath @erikd
double64_init: Check psf->sf.channels against upper bound
85c877d 
This prevents division by zero later in the code.

While the trivial case to catch this (i.e. sf.channels < 1) has already
been covered, a crafted file may report a number of channels that is
so high (i.e. > INT_MAX/sizeof(double)) that it "somehow" gets
miscalculated to zero (if this makes sense) in the determination of the
blockwidth. Since we only support a limited number of channels anyway,
make sure to check here as well.

CVE-2017-14634

Closes: #318
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
@YangY-Xiao
Copy link

Actually, commit cb3c87a can handle this issue.

-	psf->sf.frames = psf->datalength / psf->blockwidth ;
+	psf->sf.frames = psf->blockwidth > 0 ? psf->datalength / psf->blockwidth : 0 ;

I am not sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@fgeek @erikd @YangY-Xiao @Xin-Jiang