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.

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

out of bounds read in sf_write_int #427

YourButterfly opened this Issue Nov 22, 2018 · 7 comments


None yet
6 participants

YourButterfly commented Nov 22, 2018


libsndfile: Version released 1.0.28


An issue was discovered in libsndfile 1.0.28. There is an out of bounds read at function sf_write_int, will lead to a denial of service or the others.

./sndfile-deinterleave tmp/id\:000000\,sig\:06\,src\:000000\,op\:havoc\,rep\:16
Input file : tmp/id:000000,sig:06,src:000000,op:havoc,rep:16
Output files :
==49998==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fb21f1413c6 bp 0x7ffe8d3042c0 sp 0x7ffe8d27ba80 T0)
==49998==The signal is caused by a READ memory access.
==49998==Hint: address points to the zero page.
    #0 0x7fb21f1413c5 in sf_write_int /home/pwd/fuzz/fuzz-wavpack/libsndfile-1.0.28/src/sndfile.c:2257:2
    #1 0x5137b2 in deinterleave_int /home/pwd/fuzz/fuzz-wavpack/libsndfile-1.0.28/programs/sndfile-deinterleave.c:171:4
    #2 0x5137b2 in main /home/pwd/fuzz/fuzz-wavpack/libsndfile-1.0.28/programs/sndfile-deinterleave.c:134
    #3 0x7fb21e138b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #4 0x41a519 in _start (/home/pwd/fuzz/fuzz-wavpack/libsndfile-1.0.28/installed-asan/bin/sndfile-deinterleave+0x41a519)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/pwd/fuzz/fuzz-wavpack/libsndfile-1.0.28/src/sndfile.c:2257:2 in sf_write_int

debug info

In function deinterleave_int, 'ch' is 0x10 , leads to the array bounds, and then crash in function sf_write_int .

// source:sndfile-deinterleave.c+170 
    165	 	do
    166	 	{	read_len = sf_readf_int (state->infile, state->din.i, BUFFER_LEN) ;
    168	 		for (ch = 0 ; ch < state->channels ; ch ++)
    169	 		{	for (k = 0 ; k < read_len ; k++)
		// state=0x00007ffffff75438  →  [...]  →  0x0000000000000000, ch=0x10, k=0x0
 →  170	 				state->dout.i [k] = state->din.i [k * state->channels + ch] ;
    171	 			sf_write_int (state->outfile [ch], state->dout.i, read_len) ;
    172	 			} ;
    173	 		}
    174	 	while (read_len > 0) ;
gef➤  p state->channels
$3 = 0xff
gef➤  p state->outfile 
$6 = {0x555555769300, 0x55555576c800, 0x55555576fd00, 0x555555773200, 0x555555776700, 0x555555779c00, 0x55555577d100, 0x555555780600, 0x555555783b00, 0x555555787000, 0x55555578a500, 0x55555578da00, 0x555555790f00, 0x555555794400, 0x555555797900, 0x55555579ae00}

// source:sndfile.c+2257
		// sndfile=0x00007ffffff75408  →  0xf62d0000f7db0000, psf=0x00007ffffff75410  →  0xf62d0000f7db0000
 → 2257	 	VALIDATE_SNDFILE_AND_ASSIGN_PSF (sndfile, psf, 1) ;
   2259	 	if (len <= 0)
   2260	 	{	psf->error = SFE_NEGATIVE_RW_LEN ;
   2261	 		return 0 ;
   2262	 		} 
[#0] Id 1, Name: "sndfile-deinter", stopped, reason: SIGSEGV



this bug is reported by pwd@360TeamSeri0us,
please send email to if you have some quetion.


This comment has been minimized.

carnil commented Nov 22, 2018

This issue was assigned CVE-2018-19432

@evpobr evpobr added the Bug label Nov 23, 2018


This comment has been minimized.


evpobr commented Nov 23, 2018

Thanks. @erikd usually does bugfixing. Can you check this bug exists in master brunch?


This comment has been minimized.

YourButterfly commented Nov 23, 2018

Thanks, this bug is fixed by checking out the value of channels, in master brunch.
Can you keep this issue active before a new version is released?

Have a nice day!

@evpobr evpobr added this to the v1.0.29 milestone Nov 23, 2018

@evpobr evpobr added wontfix and removed Bug labels Nov 23, 2018

@evpobr evpobr self-assigned this Nov 23, 2018


This comment has been minimized.


evpobr commented Nov 23, 2018

Probably duplicate of #346. Fixed by 6f32662.


This comment has been minimized.

rjoshi18 commented Dec 4, 2018

Hi @YourButterfly @evpobr could You please confirm, whether this issue got fixed or not?


This comment has been minimized.


erikd commented Dec 4, 2018

could You please confirm, whether this issue got fixed or not?

The code is here in github. Is it not possible for you to confirm?


This comment has been minimized.

hlef commented Dec 7, 2018

The poc defines a number of channels = 255 > MAX_CHANNELS (=16). This triggers a first overflow which is silently ignored in sndfile-deinterleave.c:main:

for (ch = 0 ; ch < state.channels ; ch++) // state.channels is 255 here
{	...

	if ((state.outfile [ch] = sf_open (filename, SFM_WRITE, &sfinfo)) == NULL) // state.outfile is a char[16] array
	{	printf ("Not able to open output file '%s'\n%s\n", filename, sf_strerror (NULL)) ;
		exit (1) ;
	} ;

} ;

This is the main problem. If a file defines a number of channels > MAX_CHANNELS we should either artificially reduce the number of channels or reject it.

Hence this issue is not a duplicate of #346 but rather a duplicate of #397 fixed in aaea680.

(FTR, issue #397 was assigned CVE-2018-13139)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment