Bug 1702061 - Broken tarballs – incorrectly generated C code – Invalid read of size 4 in folks_potential_match_potential_match
Summary: Broken tarballs – incorrectly generated C code – Invalid read of size 4 in fo...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: folks
Version: 29
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
Assignee: Brian Pepple
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-22 20:56 UTC by Christian Stadelmann
Modified: 2019-04-22 22:00 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
Diff between tarball and git tag for 0.11.4 upstream release (30.40 KB, text/plain)
2019-04-22 21:23 UTC, Christian Stadelmann
no flags Details

Description Christian Stadelmann 2019-04-22 20:56:02 UTC
Description of problem:
The source tarballs used to build folks-0.11.4 contain C files which they should not. The C files have been generated with a buggy version of vala which optimizes array bounds checks away. The broken C code causes memory access violations such as "Invalid read of size 4 in folks_potential_match_potential_match". As the C files exist already, they are not being regenerated with a more recent (less buggy) valac and so they land in the RPM. See this upstream URL for more details: https://gitlab.gnome.org/GNOME/folks/issues/101

Version-Release number of selected component (if applicable):
folks-0.11.4-8.fc29.x86_64

How reproducible:
always

Steps to Reproduce:
1. Have a look at the source tarball
2. Have a look at the source RPM
3. Run any folks application under valgrind

Actual results:
1. Contains C files generated by buggy valac version
2. Contains the C files from the tarball
3. Has memory access bugs caused by buggy valac version

Expected results:
1. Contain no C files (this is an upstream bug)
2. Regenerate the C files from .vala files
3. Have no memory access bugs.

Additional info:
Using the auto-generated tarball from git instead of the official tarball should work around this issue for now. URL: https://gitlab.gnome.org/GNOME/folks/-/archive/0.11.4/folks-0.11.4.tar.bz2

Comment 1 Christian Stadelmann 2019-04-22 21:23:45 UTC
Created attachment 1557268 [details]
Diff between tarball and git tag for 0.11.4 upstream release

I'm unsure whether it is the right way to

* Download the git tag instead of the tarball, then call "./autogen.sh" within the spec file just before the "%configure" line

or

* Delete all the *.c, *.h and possibly some other files too from the tarball. See the attached diff for a potential list of files to be affected.

Comment 2 Christian Stadelmann 2019-04-22 22:00:33 UTC
(In reply to Christian Stadelmann from comment #1)
> * Delete all the *.c, *.h and possibly some other files too from the
> tarball. See the attached diff for a potential list of files to be affected.

Files to be deleted:
*.c: delete [file].c if [file].vala exists
*.h: delete [file].h if [file].vala exists
*.stamp
*.gir
*.vapi for some files (but not all of them?)

It's unclear to me whether this can be fixed downstream at all or whether the tarball is just so horribly broken that the package cannot be rebuilt with a non-broken valac at all.


Note You need to log in before you can comment on or make changes to this bug.