Bug 32561

"Patch available from Fedora": I could not find it, but it must be there.

This version 0.3.6 is 10y old, and had a flurry of patches 6-5y ago.
The project site is http://www.68k.org/~michael/audiofile/

Assigning globally.

Assignee: bugsquad => pkg-bugs

For Cauldron and Mageia 9, a patch from Fedora was added into SVN.

Suggested advisory:
========================

The updated packages fix a security vulnerability:

In autofile Audio File Library 0.3.6, there exists one memory leak vulnerability in printfileinfo, in printinfo.c, which allows an attacker to leak sensitive information via a crafted file. The printfileinfo function calls the copyrightstring function to get data, however, it dosn't use zero bytes to truncate the data. (CVE-2022-24599)

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24599
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WTETOUJNRR75REYJZTBGF6TAJZYTMXUY/
========================

Updated packages in core/updates_testing:
========================
audiofile-0.3.6-12.1.mga9
lib(64)audiofile1-0.3.6-12.1.mga9
lib(64)audiofile-devel-0.3.6-12.1.mga9

from SRPM:
audiofile-0.3.6-12.1.mga9.src.rpm

Assignee: pkg-bugs => qa-bugs
Whiteboard: MGA9TOO, MGA8TOO => (none)
Status comment: Patch available from Fedora => (none)
Status: NEW => ASSIGNED
Version: Cauldron => 9

Advisory from comment 3 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
CC: (none) => marja11

Tested on Real Hardware Mageia 9 x86_64 lxq

Install current version of audio file
Download POC from https://github.com/mpruett/audiofile/issues/60

sfinfo ./heapleak_poc.aiff
File Name      ./heapleak_poc.aiff
File Format    Audio Interchange File Format (aiff)
Data Format    unknown
Audio Data     0 bytes begins at offset 0 (0 hex)
               0 channel, -1 frames
Sampling Rate  0.00 Hz
Duration       -inf seconds
Copyright      C▒

sfinfo ./libleak_poc.aiff
File Name      ./libleak_poc.aiff
File Format    Audio Interchange File Format (aiff)
Data Format    unknown
Audio Data     0 bytes begins at offset 0 (0 hex)
               0 channel, -1 frames
Sampling Rate  0.00 Hz
Duration       -inf seconds
Copyright      Copyright 1991,����

Update to testing versions of audiofile and lib64audiofile1 without issues

sfinfo ./heapleak_poc.aiff
File Name      ./heapleak_poc.aiff
File Format    Audio Interchange File Format (aiff)
Data Format    unknown
Audio Data     0 bytes begins at offset 0 (0 hex)
               0 channel, -1 frames
Sampling Rate  0.00 Hz
Duration       -inf seconds
Copyright      C

sfinfo ./libleak_poc.aiff
File Name      ./libleak_poc.aiff
File Format    Audio Interchange File Format (aiff)
Data Format    unknown
Audio Data     0 bytes begins at offset 0 (0 hex)
               0 channel, -1 frames
Sampling Rate  0.00 Hz
Duration       -inf seconds
Copyright      Copyright 1991, 

Can't run the python2 script in the POC files but this look good to me

Whiteboard: (none) => MGA9-64-0K

@Thomas: I not feel right validate myself this, If my test is good enough for you, please validate this

Looks OK to me. Validating.

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

(In reply to Thomas Andrews from comment #7)
> Looks OK to me. Validating.

I see MGA9-64-0K on the whiteboard, but here https://madb.mageia.org/tools/updates I don't see an OK at all and there is no big yellow dot next to 9, but a light grey one.

Could that be because the _new_ version is in the SRPM field instead of the _previous_ one?? ....Removing the version there.

I hope the OK appears while I add this comment :-)

Source RPM: audiofile-0.3.6-12.mga9.src.rpm => audiofile

(In reply to Marja Van Waes from comment #8)
> (In reply to Thomas Andrews from comment #7)
> > Looks OK to me. Validating.
> 
> I see MGA9-64-0K on the whiteboard, but here
> https://madb.mageia.org/tools/updates I don't see an OK at all and there is
> no big yellow dot next to 9, but a light grey one.
> 
> Could that be because the _new_ version is in the SRPM field instead of the
> _previous_ one?? ....Removing the version there.
> 
> I hope the OK appears while I add this comment :-)

No, no difference. CC'ing Dave Hodgins

CC: (none) => davidwhodgins

Looks like I put "0K" instead of "OK" in the Whiteboard. I fixed it.

I'm pleading fat, aging fingers. ;-)

I looked it over, and I'm vindicated! Katnatek is the one who made the typo. Looks like we are all human after all.

LOL

Thanks for fixing it.

I'm glad there are others like me around (I once wrote ẃ instead of w in an xml warning tag, took me a long time to figure out what was wrong).

(In reply to Thomas Andrews from comment #11)
> I looked it over, and I'm vindicated! Katnatek is the one who made the typo.
> Looks like we are all human after all.

My good!, sorry for that, Thank you, I'll try to not make that mistakes

I copy/paste from a text file ...
$ cat validate 
MGA9-64-OK
MGA9-32-OK
MGA8-64-OK
MGA8-32-OK
has_procedure
advisory
FOR_ERRATA, IN_ERRATA
validated_update
Backport, validated_backport

sysadmin-bugs@ml.mageia.org

When I'm creating and advisory for svn using the mgaadv command, I copy/paste
the bug number, as it's critical to get right.

I make typos a lot too, and tend to see what I know it should be instead of
what's there when I proofread it. I learned a long time ago to make the
computer do tedious things when ever possible, as I'm not good at it. :-)

Could someone please correct the SRPM field to be the current version (i.e. the version the bug was reported against)?

(In reply to David Walser from comment #15)
> Could someone please correct the SRPM field to be the current version (i.e.
> the version the bug was reported against)?

Done!

Source RPM: audiofile => audiofile-0.3.6-12.mga9.src.rpm

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

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

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

(In reply to Dave Hodgins from comment #14)

> 
> When I'm creating and advisory for svn using the mgaadv command, I copy/paste
> the bug number, as it's critical to get right.
> 

I used to read it forward and backwards and forwards again, to be sure that it was exactly the same. But this morning I noticed that I had created 32588.adv for bug 32558. I'll c&p the bug number, too, from now on.

Another thing I found out, is that I should (whenever possible) open only one bug report at the same time. It is otherwise too easy put a comment for one bug report in a different one, or to accidentally gather data from the wrong bug report for an advisory.