Created attachment 14203 [details]
0015-Partial-fix-of-CVE-2019-13147.patch

This patch from debian can be applied as it is :
our version of /libaudiofile/NeXT.cpp is the same as for debian

Created attachment 14204 [details]
0014-Partial-fix-of-CVE-2019-13147.patch

NB important

In the order of utilization of the patches, this 0014 patch needs absolutely to be applied after 
07_Check-for-multiplication-overflow-in-sfconvert.patch

since it applies on /sfcommands/sfconvert.c after it has been patched by
07_Check-for-multiplication-overflow-in-sfconvert.patch

Thank you once more Philippe for your diligent work.

Nicolas, saw that you were already CC'd; but because you did the patch mentioned in comment 0 for CVE-2022-24599, seems sensible to assign this to you. Re-assign to pkg-bugs if you prefer.

QA Contact: (none) => security
Assignee: bugsquad => nicolas.salguero
CC: nicolas.salguero => (none)
Component: RPM Packages => Security

(In reply to Lewis Smith from comment #3)
> Thank you once more Philippe for your diligent work.
> 
> Nicolas, saw that you were already CC'd; but because you did the patch
> mentioned in comment 0 for CVE-2022-24599, seems sensible to assign this to
> you. Re-assign to pkg-bugs if you prefer.

Hi Lewis

I think there's a little misunderstanding :
It's not me but Nicolas Salguero that added the patch from Fedora...

I wouldn't have modified this package without advertising, since there's no official maintainer...

Nevertheless, before submitting a package to the BS I always use mock to test the build on all arches
Now I'm stuck because mock doesn't work anymore for arm arches (armv7hl or aarch64) neither for Mageia9 nor for Cauldron (see https://bugs.mageia.org/show_bug.cgi?id=32607)

I prefer for now that a better packager than me does this update

(I built it on mock only for x86_64 but can't know if it's OK for arm)

I tested the build on mock for x86_64

It seems OK

I will push the whole thing (patches and spec) to svn for Mageia9 and Cauldron

But before submitting audiofile to the BS we need to think about all the programs having BuildRequires pkgconfig (audiofile) 
or Requires  lib(64)audiofile1
They perhaps need to be rebuilt ?

I know only some of them :
fuse-emulator-utils
k3b 
kvirc
kwave
lib64ecasound24
lib64kwave23
lib64spectrum9
mpd
normalize
opencpn-weatherfax-plugin
terminatorx

audiofile is in the svn for Mageia9 and Cauldron
but I didn't submit it

PS
k3b doesn't depend directly on audiofile
indedd k3b depends on normalize which depends itself on audiofile

The order to rebuild them is

fuse-emulator-utils
kvirc
kwave
lib64ecasound24
lib64kwave23
lib64spectrum9
mpd
normalize  and after normalize has been rebuilt, then k3b 
terminatorx

NB
opencpn-weatherfax-plugin is already ready to be rebuilt (it's in the svn with an incremented  mkrel for Mageia9 and for Cauldron)
I will submit it after audiofile is submitted

Did the library major get updated?

I just came here to ask the same thing. If not, then all these rebuilds should not be necessary. And it sounds like k3b doesn't need to be rebuilt regardless, if libaudio is only an indirect dependency.

(In reply to David Walser from comment #7)
> Did the library major get updated?

I didn't touch the library major number...

But I wonder if I should I have done this :
this is a very old source, that has never been updated upstream since 2013...
it's a BuildRequires for some program such as 
ecasound 
fuse-emulator
fuse-emulator-utils 
kvirc 
kwave 
libspectrum 
normalize
opencpn-weatherfax-plugin (that I maintain and intend to rebuild)

K3b has only Requires on normalize (no need to rebuild k3b !)

Since it is always used it has been patched several times (a first patch in 2015 for CVE-2015-7747 !)

Since the last mass rebuild three important patches for CVE had to be added :
1 for CVE-2022-24599 by Dan
2 for CVE-2019-13147 by me just now

That's the reason why I ask if the programs having it as BuildRequire must be rebuilt after the corrected audiofile has been submitted...

Maybe would it be necessary to modify the library major even the original source is always the same ?

> Maybe would it be necessary to modify the library major even the original
> source is always the same ?

Hi,

No, it isn't.  Fixing CVEs in the internal code of a library should never require rebuilding software that depend on that library.

A library is a black box and you should be able to totally change the code of that library without any impact on software that depend on that library, providing you do not change the API and the ABI.

(In reply to Nicolas Salguero from comment #10)
> > Maybe would it be necessary to modify the library major even the original
> > source is always the same ?
> 
> Hi,
> 
> No, it isn't.  Fixing CVEs in the internal code of a library should never
> require rebuilding software that depend on that library.
> 
> A library is a black box and you should be able to totally change the code
> of that library without any impact on software that depend on that library,
> providing you do not change the API and the ABI.

I understand this when a program simply Requires a library

But when for building a program, it has a BuildRequires on this devel library ? 
is this not a problem when this devel library has been modified with several patches?

Maybe a silly question ! But it's a way to be taught   :-)

When a program requires a library, generally, it is because building that program requires the devel library.  It is not very common to dlopen a library.

(In reply to Nicolas Salguero from comment #12)
> When a program requires a library, generally, it is because building that
> program requires the devel library.  It is not very common to dlopen a
> library.

What I meant is that I have built audiofile with a modified source (patched)
by consequence libaudiofile-devel has been modified too ...

If pkgconfig(audiofile) is a BuildRequires for an other program
Doesn't this other program have to be rebuilt upon this modified lib devel ?

libaudiofile is not a so simple Requires in this case

No, other packages would only need to be rebuilt if the patches changed the library ABI, which would usually not be the case.  We almost never run into that issue when patching.  It's when we update a library to a new version where the major has changed (a signal from upstream that the ABI has changed) that we have to rebuild dependent packages.

OK
so I may submit audiofile to Cauldron and Mageia9/updates-testing without any fear
(even if I can't test the build for arm with mock)

Since the previous submission by Nicolas with his patch was OK it may be built easily for all arches by the BS

Yes don't worry about ARM.

That's not an advisory :o).  It should just list/describe the issue(s) actually being fixed by the (stable Mageia release) update.  So basically the CVE description for CVE-2019-13147 in this case.

Hi,

CVE-2022-24599 was already fixed in bug 32561 so only CVE-2019-13147 has to appear in the advisory.

Moreover, when fixing a bug in a stable version of the distribution, you should define or increment the subrel rather than increment the release number, contrary to Cauldron where you should always increase the release number, like you did.

And a little point of attention for the testers, the package of the library is lib(64)audiofile1-0.3.6-14.mga9.(%arch)rpm.

Best regards,

Nico.

Status: NEW => ASSIGNED
Assignee: nicolas.salguero => qa-bugs

Advisory based on comment 19 and comment 20 added to SVN. Please remove the "advisory" keyword if it needs to be changed. It also helps when obsolete advisories are tagged as "obsolete"

Keywords: (none) => advisory

Hi Nicolas


Sorry for the bad numbering inside Mageia9 : when I used mgarepo to apply my patches I used the downloaded srpm from Cauldron added my patches , and incremented the %mkrel in its spec file.

then I used the same modified spec and sources for Mageia9 updates

About the Advisory :

I have worked for a long time with the dev of the upstream source of opencpn-weatherfax-plugin  to help him to update their bundled source of audiofile, comparing it with our own source from Mageia9/core/release (in which the patch for CVE-2022-24599 didn't exist yet) that's the one I had used to package opencpn-weatherfax-plugin for Mageia

Besides this I looked at the patches used by Debian and discovered that CVE-2019-13147 and CVE-2022-24599 had not been corrected in Mageia9/core/release

Might I rewrite the Advisory and mention only CVE-2022-24599 ?

(In reply to Philippe Didier from comment #22)

> 
> Besides this I looked at the patches used by Debian and discovered that
> CVE-2019-13147 and CVE-2022-24599 had not been corrected in
> Mageia9/core/release

I don't know when you looked, but the fix for CVE-2022-24599 was pushed to core/updates on December 4
https://bugs.mageia.org/show_bug.cgi?id=32561

The current advisory can be seen here:
https://svnweb.mageia.org/advisories/32608.adv?revision=15382&view=markup

(In reply to Marja Van Waes from comment #23)
> (In reply to Philippe Didier from comment #22)
> 
> > 
> > Besides this I looked at the patches used by Debian and discovered that
> > CVE-2019-13147 and CVE-2022-24599 had not been corrected in
> > Mageia9/core/release
> 
> I don't know when you looked, but the fix for CVE-2022-24599 was pushed to
> core/updates on December 4
> https://bugs.mageia.org/show_bug.cgi?id=32561
> 
> The current advisory can be seen here:
> https://svnweb.mageia.org/advisories/32608.adv?revision=15382&view=markup

You may have an answer in the fact that I began to test the build of the updated audiofile with mock in the end of november, ( the fix for CVE-2022-24599 was not yet in  core/updates)

Since november I have struggled with mock to test builds for arm arches before submitting to the BS !!! 
(I always test the build locally before providing an update to Mageia)
I wrote to the dev mailing list about this problem on the 27th of november
(there are now 2 bug reports about mock : #32607 #32620)

Finally when I created this bug report I saw that a fix had been proposed to Cauldron for CVE-2022-24599... but I didn't verified if it was in updates too

nevertheless I have modified the names of the patches by numbering them so that we are sure to apply them in the right order, since some of them are incremental

Sorry if I seem slow, but I had been slowed by a bug of one tool (mock)

(In reply to Philippe Didier from comment #24)

> Sorry if I seem slow, but I had been slowed by a bug of one tool (mock)

No worries, we're all human, we all miss things from time to time, and it is great that you're helping :-)

No problem we human can be bit slow someties.....i have some time to spend qa team testing stuff...next week few weeks christmas holiday stops january 2024..

Using QARepo I get "lib64audiofile-0.3.6-14.mga9 not found in the remote repository" , the two others seem OK.

CC: (none) => herman.viaene

Here is a corrected Advisory since there was already one about CVE-2022-24599


Suggested Advisory
==================
2 patches are added to audiofile source to correct vulnerabilities

CVE-2019-13147
In Audio File Library (aka audiofile) 0.3.6, there exists one NULL pointer dereference bug in ulaw2linear_buf in G711.cpp in libmodules.a that allows an attacker to cause a denial of service via a crafted file.


Updated packages in Core/updates_testing
========================================
audiofile-0.3.6-14.mga9.(%arch)rpm
lib(64)audiofile-0.3.6-14.mga9.(%arch)rpm
lib(64)audiofile-devel-0.3.6-14.mga9.(%arch)rpm


Source RPM
-----------
audiofile-0.3.6-14.mga9.srpm

@ Marja

please use the Advisory from comment 28 instead of the ones in comment 19 and 20

Keywords: advisory => (none)

(In reply to Philippe Didier from comment #29)
> @ Marja
> 
> please use the Advisory from comment 28 instead of the ones in comment 19
> and 20

The current advisory is here:
https://svnweb.mageia.org/advisories/32608.adv?revision=15382&view=markup

I'm fine with adding:

  2 patches are added to audiofile source to correct a vulnerability 

at the top of the description, but it feels wrong to talk about vulnerabilities. IIUC, CVE-2019-13147 is one vulnerability, not two or more (even if one patch wasn't enough to fix it completely).

(In reply to Marja Van Waes from comment #30)

> 
> The current advisory is here:
> https://svnweb.mageia.org/advisories/32608.adv?revision=15382&view=markup
> 
> I'm fine with adding:
> 
>   2 patches are added to audiofile source to correct a vulnerability 
> 
> at the top of the description, but it feels wrong to talk about
> vulnerabilities. IIUC, CVE-2019-13147 is one vulnerability, not two or more
> (even if one patch wasn't enough to fix it completely).

Thanks for having corrected this long sequence of mistakes :
the last and not least being a grammar typo ... but I need some indulgence : English is not my native language ;o)

Best Regards

(In reply to Philippe Didier from comment #31)

> 
> Thanks for having corrected this long sequence of mistakes :
> the last and not least being a grammar typo ... but I need some indulgence :
> English is not my native language ;o)
> 
No problem, I'm glad I don't have to write advisories in French ;-)

Apart from that, I may have made more mistakes than you recently.

The advisory has been enhanced with the line about the 2 patches.

Keywords: (none) => advisory

Suggested Advisory
==================
2 patches are added to audiofile source to correct vulnerabilities

CVE-2019-13147
In Audio File Library (aka audiofile) 0.3.6, there exists one NULL pointer dereference bug in ulaw2linear_buf in G711.cpp in libmodules.a that allows an attacker to cause a denial of service via a crafted file.


Updated packages in Core/updates_testing
========================================
audiofile-0.3.6-14.mga9
lib(64)audiofile1-0.3.6-14.mga9
lib(64)audiofile-devel-0.3.6-14.mga9


Source RPM
-----------
audiofile-0.3.6-14.mga9.srpm

Tested in Real Hardware Magiea 9 x86_64

Download and extract the POC in https://github.com/mpruett/audiofile/issues/54

sfconvert poc output format voc
Violación de segmento (`core' generado)

Updates to testing packages without issue

sfconvert poc output format voc
Audio File Library: invalid file with 1633771873 channels [error 15]
Could not open file 'poc' for reading.

Whiteboard: (none) => MGA9-64-OK

Validating.

Keywords: (none) => validated_update
CC: (none) => andrewsfarm, sysadmin-bugs

(In reply to katnatek from comment #34)
> Tested in Real Hardware Magiea 9 x86_64
> 
> Download and extract the POC in
> https://github.com/mpruett/audiofile/issues/54
> 
> sfconvert poc output format voc
> Violación de segmento (`core' generado)
> 
> Updates to testing packages without issue
> 
> sfconvert poc output format voc
> Audio File Library: invalid file with 1633771873 channels [error 15]
> Could not open file 'poc' for reading.

What is surprising is that 14_Partial-fix-of-CVE-2019-13147.patch is supposed to bring the correction of the 1633771873 channels. 

But indeed the poc file you use is not a real poc file to test sfconvert !
It's a crafted file to show the possibility of attack corrected by 
13_Partial-fix-of-CVE-2019-13147.patch

If you look at its content you will see that it doesn't looks like an e-mail !

NB what is used by the programs requiring the library of audiofile (and not the binary) is the capacity to manipulate audiofiles
some programs has a BuildRequire on its devel library

don't worry about the binary

Bu if you want to really test sfconvert use a real .poc file not the one you tried to convert : it's garbage for attacking and create denial of service 
 ;o)

(In reply to Philippe Didier from comment #36)
> (In reply to katnatek from comment #34)
> > Tested in Real Hardware Magiea 9 x86_64
> > 
> > Download and extract the POC in
> > https://github.com/mpruett/audiofile/issues/54
> > 
> > sfconvert poc output format voc
> > Violación de segmento (`core' generado)
> > 
> > Updates to testing packages without issue
> > 
> > sfconvert poc output format voc
> > Audio File Library: invalid file with 1633771873 channels [error 15]
> > Could not open file 'poc' for reading.
> 
> What is surprising is that 14_Partial-fix-of-CVE-2019-13147.patch is
> supposed to bring the correction of the 1633771873 channels. 
> 
> But indeed the poc file you use is not a real poc file to test sfconvert !
> It's a crafted file to show the possibility of attack corrected by 
> 13_Partial-fix-of-CVE-2019-13147.patch
> 
> If you look at its content you will see that it doesn't looks like an e-mail
> !

I follow the links of CVE https://nvd.nist.gov/vuln/detail/CVE-2019-13147, I think is good the tool reject to open the bad file, but the github link not provide an example of how the output looks after solve the issue, I will test application that require the library if I can

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2023-0347.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED