libopenmpt
No description set
- Developed at multimedia:libs
- Sources inherited from project openSUSE:Factory
-
4
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout openSUSE:Factory:RISCV/libopenmpt && cd $_
- Create Badge
Refresh
Refresh
Source Files
Filename | Size | Changed |
---|---|---|
baselibs.conf | 0000000044 44 Bytes | |
libmodpulg-pcfile.patch | 0000000509 509 Bytes | |
libopenmpt-0.4.9+release.autotools.tar.gz | 0001470366 1.4 MB | |
libopenmpt.changes | 0000015196 14.8 KB | |
libopenmpt.spec | 0000006427 6.28 KB |
Revision 22 (latest revision is 47)
Dominique Leuenberger (dimstar_suse)
accepted
request 736008
from
Tomáš Chvátal (scarabeus_iv)
(revision 22)
- Update to version 0.4.9 bsc#1153102 CVE-2019-17113 * [Sec] libmodplug: C API: Limit the length of strings copied to the output buffer of ModPlug_InstrumentName() and ModPlug_SampleName() to 32 bytes (including terminating null) as is done by original libmodplug. This avoids potential buffer overflows in software relying on this limit instead of querying the required buffer size beforehand. libopenmpt can return strings longer than 32 bytes here beacuse the internal limit of 32 bytes applies to strings encoded in arbitrary character encodings but the API returns them converted to UTF-8, which can be longer. (reported by Antonio Morales Maldonado of Semmle Security Research Team) (r12129) * [Sec] libmodplug: C++ API: Do not return 0 in CSoundFile::GetSampleName() and CSoundFile::GetInstrumentName() when a null output pointer is provided. This behaviour differed from libmodplug and made it impossible to determine the required buffer size. (r12130) - Update to version 0.4.8: * [Sec] Possible crash due to out-of-bounds read when playing an OPL note with active filter in S3M or MPTM files (r12118). - Update to version 0.4.7: * J2B: Ignore notes with non-existing instrument (fixes Ending.j2b)
Comments 0