|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #58054 Segmentation Fault when using id3_get_tag()
Submitted: 2008-02-22 04:38 UTC Modified: 2017-07-24 21:48 UTC
Avg. Score:4.3 ± 0.9
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: charno at charno dot ch Assigned:
Status: Duplicate Package: id3 (PECL)
PHP Version: 5.1.4 OS: Debian Linux Sarge (3.1)
Private report: No CVE-ID: None
 [2008-02-22 04:38 UTC] charno at charno dot ch

I get a SegFault everytime I read Tags from MP3 Files. It's definitively this function, have a look at the example script!

First I tought, that it maybe could be because of the memory_limit when parsing the mp3's, but the error raises with a memory limit and just one parsed file, too.

Reproduce code:
        $id3 = id3_get_tag("./mp3/test.mp3");

Expected result:
The $id3-Variable should be an array of id3-tags
(I'm not the Developer of the PHP-Application, just the Server Admin. So it's possible that I'm wrong with this!)

Actual result:
Here I have a backtrace, without Debugging Symbols. Is it sufficient to recompile just the Module with debugging-symbols to get them in the backtrace?

#2832 0x7273752f in ?? ()
#2833 0x6e69622f in ?? ()
#2834 0x7068702f in ?? ()
#2835 0x00312e35 in ?? ()
#2836 0x00000000 in ?? ()


id3_segfault (last revision 2012-05-10 17:13 UTC by mls at o2 dot pl)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-02-22 04:43 UTC] charno at charno dot ch
Just forgot to specify the New Memory Limit: It's at 64M
 [2012-12-29 16:33 UTC] matt at majenko dot co dot uk
Still getting the problem even with the patch.  Backtrace shows "len" of _php_strnoffcpy is garbled:

Program received signal SIGSEGV, Segmentation fault.
_php_strnoffcpy (dest=0xb6f70024 "", src=0xb76f1024 "UFID", offset=480, len=7667827) at /home/matt/id3/id3-0.2/id3.c:974
974			dest[i] = src[offset + i];
(gdb) bt
#0  _php_strnoffcpy (dest=0xb6f70024 "", src=0xb76f1024 "UFID", offset=480, len=7667827) at /home/matt/id3/id3-0.2/id3.c:974
#1  0x00ff1f12 in _php_id3v2_get_tag (stream=0x89a7c00, return_value=0x89a0ef4, version=28) at /home/matt/id3/id3-0.2/id3.c:694
#2  0x00ff21fd in zif_id3_get_tag (ht=1, return_value=0x89a0ef4, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /home/matt/id3/id3-0.2/id3.c:345
#3  0x0839866a in ?? ()
#4  0x083434ee in execute ()
#5  0x0831c239 in zend_execute_scripts ()
#6  0x082c2e1e in php_execute_script ()
#7  0x0806b47f in ?? ()
#8  0x0070f113 in __libc_start_main (main=0x8069c00, argc=2, ubp_av=0xbffff984, init=0x83b9850 <__libc_csu_init>, fini=0x83b98c0 <__libc_csu_fini>, 
    rtld_fini=0x11eba0, stack_end=0xbffff97c) at libc-start.c:226
#9  0x0806b521 in _start ()
 [2012-12-29 17:21 UTC] matt at majenko dot co dot uk
_php_bigEndian_to_Int takes a signed char * as the first parameter.  This causes problems when the MSB of a byte is set (and not synchsafe, as in 2.3) as it causes the values to be miscalculated and huge sizes to be returned.

This is bad.

Changing the "char *" to "unsigned char *" fixes that part of the problem.  However, values don't seem to be being returned quite right (rogue characters or missing characters in strings).
 [2012-12-29 20:05 UTC] matt at majenko dot co dot uk
The rogue characters were just the UTF-16 BOM, so not a problem.  However, the UFID frame of 2.3 is decoded incorrectly and the first character of the content is lost.  _php_strnoffcpy in _php_id3v2_parseUFIDFrame copies from offset 1 - it should (for 2.3 at least) be offset 0 - it may need a special case for different versions.
 [2015-07-26 18:12 UTC]
-Status: Open +Status: Suspended
 [2015-07-26 18:12 UTC]
This may be a duplicate of bug #56848.

Anyhow, the id3 extension is unmaintained (no release for more
than 10 years). I'm suspending this report until a new maintainer
is found.
 [2017-07-24 21:48 UTC]
-Status: Suspended +Status: Duplicate
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Sun Mar 26 00:03:53 2023 UTC