Hi, James Cowgill <jcowgill@debian.org> (2017-06-20): > This update contains a number of security fixes to libopenmpt which > upstream has specifically asked me to get into stretch. Upstream asked > me to fix these earlier this month and since none of them looked > "critical" I decided to wait and file a stretch-pu bug (although maybe > I was a little lazy...) The worst bugs fixed here are NULL pointer > dereferences - I don't think there is any remote code execution here. I suspect it would be best to check with the security team anyway? > Upstream kindly backported all the fixes to the version Debian has in > stretch and they were taken from this announcement: > https://lib.openmpt.org/libopenmpt/md_announce-2017-06-02.html > > I omitted 2 patches which seem to be impossible to exploit or which > only have minor cosmetic effects. > > Debdiff attached. > Patch: debian/patches/up3-excessive-cpu-consumption-on-malformed-files-dmf-mdl.patch > --- libopenmpt-0.2.7386~beta20.3/debian/patches/up3-excessive-cpu-consumption-on-malformed-files-dmf-mdl.patch 1970-01-01 01:00:00.000000000 +0100 > +++ libopenmpt-0.2.7386~beta20.3/debian/patches/up3-excessive-cpu-consumption-on-malformed-files-dmf-mdl.patch 2017-06-20 08:58:50.000000000 +0100 > @@ -0,0 +1,351 @@ > +Description: Fix excessive CPU consumption on malformed DMF and MDL files > + See https://lib.openmpt.org/libopenmpt/md_announce-2017-06-02.html > + This patch prevents loading of DMF and MDL modules taking multiple minutes if > + the module contains truncated compressed samples. > +Origin: upstream, https://source.openmpt.org/browse/openmpt?op=revision&rev=8237 > +Bug-Debian: https://bugs.debian.org/864195 > +--- > +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ > +--- a/soundlib/Load_dmf.cpp > ++++ b/soundlib/Load_dmf.cpp > +@@ -16,6 +16,7 @@ > + #include "stdafx.h" > + #include "Loaders.h" > + #include "ChunkReader.h" > ++#include <stdexcept> > + > + OPENMPT_NAMESPACE_BEGIN > + > +@@ -1087,68 +1088,66 @@ struct DMFHTree > + int bitnum; > + int lastnode, nodecount; > + DMFHNode nodes[256]; > +-}; > +- ^^^ This update seems to be putting DMFReadBits() and DMFNewNode() functions “inside” the DMFHTree struct? I'm not a C overlord, but that's a construction I haven't seen yet. :) Anyway all I could spot was this structure update, and a function signature update, both of which not being exported as far as I can tell. So that looks good to me, except for the security team question in my first paragraph. KiBi.
Attachment:
signature.asc
Description: Digital signature