[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