Bug#914794: libmspack fails tests on big endian architectures (s390x, mips)

On 04/03/2019 05:00, Marc Dequènes (duck) wrote: Quack, On 2019-03-04 10:40, Stuart Caie wrote: I've released libmspack 0.10 and cabextract 1.9.1. They contain only fixes. Thanks a lot for being so fast. Unfortunately there is a build problem: How odd, but yes, I have a system where

Bug#914794: libmspack fails tests on big endian architectures (s390x, mips)

On 03/03/2019 04:47, Marc Dequènes (duck) wrote: Quack, On 2018-12-04 19:02, Stuart Caie wrote: This is fixed in the repository, it just hasn't been released. I'll release it in the near future. I was myself busy and we missed the Debian freeze deadline. Maybe there is still some hope

Bug#914794: libmspack fails tests on big endian architectures (s390x, mips)

On 04/12/2018 05:35, Marc Dequènes (duck) wrote: libmspack fails tests on big endian architectures (s390x, mips) This is fixed in the repository, it just hasn't been released. I'll release it in the near future. commit c19e707936947b45cf05bc9aaee68517c6c2aca6 Author: Stuart Caie Date

Bug#912687: libmspack0: Regression when extracting cabinets using -F option fixed upstream, needs to be patched

On 03/11/2018 03:15, Marc Dequènes (Duck) wrote: Stuart, as this is an important bug I guess you'll be releasing soon? Could you ping me when ready? Hi Marc, yes there'll be a release soon. Regards Stuart

Bug#868956: libmspack: CVE-2017-11423

For your information, libmspack 0.6alpha has now been released. On 06/08/17 20:22, Sebastian Andrzej Siewior wrote: On 2017-08-06 10:22:11 [+0100], Stuart Caie wrote: Commited a fix: https://github.com/kyz/libmspack/commit/17038206fcc384dcee6dd9e3a75f08fd3ddc6a38 I'll put out a release

Bug#871263: libmspack: CVE-2017-6419

On 12/08/17 20:40, Sebastian Andrzej Siewior wrote: On 2017-08-12 00:42:06 [+0100], Stuart Caie wrote: On 11/08/17 19:07, Sebastian Andrzej Siewior wrote: [0] https://security-tracker.debian.org/tracker/CVE-2017-6419 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6419 [1

Bug#871924: jlha does not support Amiga LhA files

l/mod.thunder-wall- Melted : From 24eac22c434aedfbe953db4aba001b5ec4e59445 Mon Sep 17 00:00:00 2001 From: Stuart Caie <ky...@kyzer.me.uk> Date: Sat, 12 Aug 2017 15:25:09 +0100 Subject: [PATCH] Support Amiga LhA files --- debian/patches/04_AmigaLhA.patch | 10 ++ d

Bug#871263: libmspack: CVE-2017-6419

On 11/08/17 19:07, Sebastian Andrzej Siewior wrote: [0] https://security-tracker.debian.org/tracker/CVE-2017-6419 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6419 [1] https://github.com/vrtadmin/clamav-devel/commit/a83773682e856ad6529ba6db8d1792e6d515d7f1 Stuart, is this

Bug#868956: libmspack: CVE-2017-11423

On 05/08/17 10:36, Stuart Caie wrote: libmspack is wrong to convert to unsigned without checking for errors first. When I get to my computer, I'll check all calls to mspack_system read/write/seek/tell methods, to be sure this doesn't happen anywhere else. I checked all the other mspack_system

Bug#868956: libmspack: CVE-2017-11423

On 4 Aug 2017 7:40 am, Sebastian Andrzej Siewior wrote: > > The way I see it, the problem is that the read functions returns -1 on > error and libmspack >   https://sources.debian.net/src/libmspack/0.5-1/mspack/cabd.c/#L524 > > treats the return code as unsigned

Bug#868956: libmspack: CVE-2017-11423

t consider it a vulnerability at the time and still don't consider it one now. https://github.com/kyz/libmspack/commit/3e3436af6010ac245d7a390c6798e2b81ce09191 2015-05-10 Stuart Caie <ky...@4u.net> * cabd_read_string(): correct rejection of empty strings. Thanks to Hanno Böck for finding the iss

Bug#775687: libmspack: CHM decompression: another pointer arithmetic overflow

On 18/01/2015 22:00, Sebastian Andrzej Siewior wrote: On 2015-01-18 18:59:33 [+0100], Jakub Wilk wrote: Sorry, it's me again! libmspack crashes on the attached file: As I've seen your ubsan reports, I assumed you were done. Wrong this was. $ gpg -d crash.chm.asc crash.chm $ test/chmd_md5

Bug#775498: libmspack: off-by-one buffer over-read in mspack/mszipd.c

Good find. This has been fixed in the libmspack repository. Regards Stuart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775499: libmspack: off-by-one(?) buffer under-read in mspack/lzxd.c

This happens because of the presumption i_ptr can be wound back 2 bytes. It could, until this change in 2006: 2006-08-31: Stuart Caie ky...@4u.net * lzxd_decompress(): [...] the LZX decompression stream can sometimes become odd-aligned (after an uncompressed block

Bug#773659: cabextract: null pointer dereference on a crafted CAB

On 11/01/2015 21:15, Sebastian Andrzej Siewior wrote: On 2015-01-11 16:31:30 [+], Stuart Caie wrote: This is an accurate summary. There are two cab files found, the second of Sorry for the inaccurate summary. No, the summary was accurate :) Are you also aware of the two recent reports

Bug#773659: cabextract: null pointer dereference on a crafted CAB

On 05/01/2015 20:50, Sebastian Andrzej Siewior wrote: The -search callback of the mspack library finds two cab files within the one you attached. The internal structure gets real funny. afl managed to create a .cab file which contains a valid file, followed by one which contains an invalid

Bug#772891: cabextract: hangs on a crafted CAB file

On 12/12/2014 05:00, Eric Sharkey wrote: On Thu, Dec 11, 2014 at 6:47 PM, Jakub Wilk jw...@debian.org wrote: Package: cabextract Version: 1.4-4+b1 Severity: minor Usertags: afl The attached file makes cabextract hang forever (or at least for two minutes, after which I lost my patience :-P).

Bug#640025: mod_musicindex fields

Package: libapache2-mod-musicindex Version: 1.3.5-1 If there are less MusicFields configured than the default (5), the default fields will seep through. This probably also occurs with the sort order, because the same function is used. Example: default: title artist album

Bug#393828: cabextract: support .inf files

If you could send me the INF file and a listing of the CAB file in question, I could look into writing an automatic renamer, like there is for PocketPC CAB files. However, the Microsoft description of the INF format