[Debian-med-packaging] Bug#748403: Conflicting declarations of jpeg_memory_mgr may lead to invalid function calls
Michael Tautschnig
mt at debian.org
Fri May 16 22:24:10 UTC 2014
Package: dcmtk
Version: 3.6.0-15
Usertags: goto-cc
During a rebuild of all packages in a clean sid chroot (and cowbuilder+pbuilder)
the build failed with the following error. Please note that we use our research
compiler tool-chain (using tools from the cbmc package), which permits extended
reporting on type inconsistencies at link time.
[...]
x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -DUSE_NULL_SAFE_OFSTRING -DWITH_ARITHMETIC_PATCH -DNDEBUG -c -I. -I. -I../include -I../../config/include -I../../ofstd/include \
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/libxml2 -D_REENTRANT -D_XOPEN_SOURCE_EXTENDED -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_BSD_COMPAT -D_OSF_SOURCE -D_POSIX_C_SOURCE=199506L -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security jaricom.c
g++ -Wl,-z,relro -Wl,--as-needed -Wl,--no-undefined -shared -Wl,-soname,libijg8.so.2 -o libijg8.so jcomapi.o jcodec.o jutils.o jerror.o jmemmgr.o jmemnobs.o jcapimin.o jcapistd.o jctrans.o jcparam.o jdatadst.o jcinit.o jcmaster.o jcmarker.o jcmainct.o jcprepct.o jclossls.o jclossy.o jccoefct.o jccolor.o jcsample.o jchuff.o jcphuff.o jcshuff.o jclhuff.o jcpred.o jcscale.o jcdiffct.o jcdctmgr.o jfdctfst.o jfdctflt.o jfdctint.o jdapimin.o jdapistd.o jdtrans.o jdatasrc.o jdmaster.o jdinput.o jdmarker.o jdlossls.o jdlossy.o jdhuff.o jdlhuff.o jdphuff.o jdshuff.o jdpred.o jdscale.o jddiffct.o jdmainct.o jdcoefct.o jdpostct.o jddctmgr.o jidctfst.o jidctflt.o jidctint.o jidctred.o jdsample.o jdcolor.o jquant1.o jquant2.o jdmerge.o jcarith.o jdarith.o jaricom.o
error: conflicting function declarations "jpeg8_destroy"
old definition in module jcomapi file jcomapi.c line 69
void (struct jpeg_common_struct *cinfo)
new definition in module jerror file jpeglib8.h line 1141
void (struct jpeg_common_struct *)
reason for conflict at cinfo.mem in types listed below (struct/struct):
composite type component counts differ (14/13)
struct jpeg_memory_mgr {
void * (*)(struct jpeg_common_struct *cinfo, signed int pool_id, unsigned long int sizeofobject) alloc_small;
void * (*)(struct jpeg_common_struct *cinfo, signed int pool_id, unsigned long int sizeofobject) alloc_large;
unsigned char ** (*)(struct jpeg_common_struct *cinfo, signed int pool_id, unsigned int samplesperrow, unsigned int numrows) alloc_sarray;
signed short int (**(*)(struct jpeg_common_struct *cinfo, signed int pool_id, unsigned int blocksperrow, unsigned int numrows))[64l] alloc_barray;
signed int ** (*)(struct jpeg_common_struct *cinfo, signed int pool_id, unsigned int diffsperrow, unsigned int numrows) alloc_darray;
struct jvirt_sarray_control * (*)(struct jpeg_common_struct *cinfo, signed int pool_id, signed int pre_zero, unsigned int samplesperrow, unsigned int numrows, unsigned int maxaccess) request_virt_sarray;
struct jvirt_barray_control * (*)(struct jpeg_common_struct *cinfo, signed int pool_id, signed int pre_zero, unsigned int blocksperrow, unsigned int numrows, unsigned int maxaccess) request_virt_barray;
void (*)(struct jpeg_common_struct *cinfo) realize_virt_arrays;
unsigned char ** (*)(struct jpeg_common_struct *cinfo, struct jvirt_sarray_control *ptr, unsigned int start_row, unsigned int num_rows, signed int writable) access_virt_sarray;
signed short int (**(*)(struct jpeg_common_struct *cinfo, struct jvirt_barray_control *ptr, unsigned int start_row, unsigned int num_rows, signed int writable))[64l] access_virt_barray;
void (*)(struct jpeg_common_struct *cinfo, signed int pool_id) free_pool;
void (*)(struct jpeg_common_struct *cinfo) self_destruct;
signed long int max_memory_to_use;
signed long int max_alloc_chunk;
}
struct jpeg_memory_mgr {
void * (*)(struct jpeg_common_struct *cinfo, signed int pool_id, unsigned long int sizeofobject) alloc_small;
void * (*)(struct jpeg_common_struct *cinfo, signed int pool_id, unsigned long int sizeofobject) alloc_large;
unsigned char ** (*)(struct jpeg_common_struct *cinfo, signed int pool_id, unsigned int samplesperrow, unsigned int numrows) alloc_sarray;
signed short int (**(*)(struct jpeg_common_struct *cinfo, signed int pool_id, unsigned int blocksperrow, unsigned int numrows))[64l] alloc_barray;
struct jvirt_sarray_control * (*)(struct jpeg_common_struct *cinfo, signed int pool_id, signed int pre_zero, unsigned int samplesperrow, unsigned int numrows, unsigned int maxaccess) request_virt_sarray;
struct jvirt_barray_control * (*)(struct jpeg_common_struct *cinfo, signed int pool_id, signed int pre_zero, unsigned int blocksperrow, unsigned int numrows, unsigned int maxaccess) request_virt_barray;
void (*)(struct jpeg_common_struct *cinfo) realize_virt_arrays;
unsigned char ** (*)(struct jpeg_common_struct *cinfo, struct jvirt_sarray_control *ptr, unsigned int start_row, unsigned int num_rows, signed int writable) access_virt_sarray;
signed short int (**(*)(struct jpeg_common_struct *cinfo, struct jvirt_barray_control *ptr, unsigned int start_row, unsigned int num_rows, signed int writable))[64l] access_virt_barray;
void (*)(struct jpeg_common_struct *cinfo, signed int pool_id) free_pool;
void (*)(struct jpeg_common_struct *cinfo) self_destruct;
signed long int max_memory_to_use;
signed long int max_alloc_chunk;
}
Makefile:45: recipe for target 'libijg8.so' failed
make[3]: *** [libijg8.so] Error 1
make[3]: Leaving directory '/srv/jenkins-slave/workspace/sid-goto-cc-dcmtk/dcmtk-3.6.0/dcmjpeg/libijg8'
Makefile:39: recipe for target 'libsrc-all' failed
Reviewing the code, it seems that the existence of the function pointer
alloc_darray (5fth field) is conditional on NEED_DARRAY, which in turn seems to
be set if and only if JPEG_INTERNALS is defined. This appears dangerous, as and
jpeg_memory_mgr allocated without this being set will cause jpeg8_destroy to
access the wrong field of the struct when attempting to call self_destruct:
http://sources.debian.net/src/dcmtk/3.6.0-15/dcmjpeg/libijg8/jcomapi.c?hl=74#L69
It may be possible that no such case exists, i.e., all allocated jpeg_memory_mgr
have the same size - but the chain of preprocessor macros seems dangerous here.
Best,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 859 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20140516/2fdec5f1/attachment.sig>
More information about the Debian-med-packaging
mailing list