Bug 1383565

Summary: segmentation fault when Sack.add_cmdline_package is passed an invalid RPM
Product: [Fedora] Fedora Reporter: Dan Callaghan <dcallagh>
Component: hawkeyAssignee: rpm-software-management
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: high    
Version: 24CC: grgoffe, mluscon, mmraka, packaging-team-maint, RadekHolyPublic, rpm-software-management, vmukhame
Target Milestone: ---Keywords: Patch, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-08 15:16:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
proposed patch
none
flat file of stack trace edited from /var/log/messages none

Description Dan Callaghan 2016-10-11 05:23:03 UTC
Description of problem:
If Sack.add_cmdline_package is passed a filename which ends in .rpm but is not actually a valid RPM package, any subsequent operations on the package will crash with a segfault.

Version-Release number of selected component (if applicable):
python2-hawkey-0.6.3-6.fc24.x86_64

How reproducible:
pretty easily

Steps to Reproduce:
$ : >broken.rpm
$ python
Python 2.7.12 (default, Aug  9 2016, 15:48:18) 
[GCC 6.1.1 20160621 (Red Hat 6.1.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import hawkey
>>> sack = hawkey.Sack()
>>> sack.add_cmdline_package('broken.rpm')
Segmentation fault (core dumped)

Actual results:
crash

Expected results:
Python exception

Additional info:
Program received signal SIGSEGV, Segmentation fault.
0x00007fffef6f1364 in hy_package_get_reponame (pkg=pkg@entry=0x555555825ba0) at /usr/src/debug/hawkey-0.6.3/src/package.c:317
317	    return s->repo->name;
Missing separate debuginfos, use: dnf debuginfo-install nss-3.26.0-1.0.fc24.x86_64 nss-util-3.26.0-1.0.fc24.x86_64 sssd-client-1.13.4-4.fc24.x86_64
(gdb) where
#0  0x00007fffef6f1364 in hy_package_get_reponame (pkg=pkg@entry=0x555555825ba0) at /usr/src/debug/hawkey-0.6.3/src/package.c:317
#1  0x00007fffef90dd1e in package_repr (self=0x7ffff7f680b0) at /usr/src/debug/hawkey-0.6.3/src/python/package-py.c:163
#2  0x00007ffff7a80340 in PyObject_Repr (v=v@entry=<_hawkey.Package at remote 0x7ffff7f680b0>)
    at /usr/src/debug/Python-2.7.12/Objects/object.c:381
[...]
(gdb) p pkg->id
$3 = 0
(gdb) p pkg->sack->pool->solvables[0]
$4 = {name = 0, arch = 0, evr = 0, vendor = 0, repo = 0x0, provides = 0, obsoletes = 0, conflicts = 0, requires = 0, recommends = 0, 
  suggests = 0, supplements = 0, enhances = 0}

It seems like hawkey is incorrectly populating the libsolv pool with an empty Solvable, which then crashes because s->repo is NULL. I guess an error is being ignored somewhere (instead of being raised back to Python) when loading the package into the Sack.

Comment 1 Dan Callaghan 2016-10-11 05:48:02 UTC
So I had a poke around in gdb... It seems to hit this error case in repo_add_rpm inside libsolv:

2126	  if (fread(lead, 96 + 16, 1, fp) != 1 || getu32(lead) != 0xedabeedb)
2127	    {
2128	      pool_error(pool, -1, "%s: not a rpm", rpm);
2129	      fclose(fp);
2130	      return 0;
2131	    }

The return type of repo_add_rpm is Id. I can't find any API docs for libsolv... but I'm guessing that callers are supposed to check for 0 as a return value indicating error. However hy_sack_add_cmdline_package is not doing that, it just blindly saves the id as 0 which is why it ends up pointing at the empty solvable in the pool.

Comment 2 Dan Callaghan 2016-10-12 03:05:33 UTC
Created attachment 1209414 [details]
proposed patch

Here is a proposed patch against hawkey 0.6.3.

Comment 3 Igor Gnatenko 2016-10-12 05:19:31 UTC
Thanks a lot for patch. I submitted PR on behalf of you: https://github.com/rpm-software-management/libhif/pull/201


Do you need it for hawkey as well or it can be just included into libdnf (F26+)?

Comment 4 Dan Callaghan 2016-10-12 05:25:43 UTC
This bug is affecting rpmdeplint, that's why I found it originally: bug 1382531.

It would be helpful for us if you could fix this in RHEL7 hawkey (and ideally Fedora hawkey also) since we are planning to deploy a production service using rpmdeplint on RHEL7 in the future.

Comment 5 Honza Silhan 2016-10-17 11:49:12 UTC
we should backport patch to hawkey in RHEL and in libdnf upstream version.

Comment 7 Dan Callaghan 2016-12-16 01:01:48 UTC
I actually wrote the patch against the version of hawkey in RHEL7 so there is no actual backporting needed. You can just apply it. :-)

Comment 8 Igor Gnatenko 2017-01-30 12:29:45 UTC
*** Bug 1408662 has been marked as a duplicate of this bug. ***

Comment 9 George R. Goffe 2017-02-20 00:18:40 UTC
Igor,

I don't understand how you guys can close this bug because I'm STILL having the problem. 

Running gnome-abrt shows NOTHING... Not trapping this segfault?

From 13 February 2017 I have 2016 messages about dnf segfaults!

I have a core file but it's too big to attach to this bug report. Where do you guys put your dumps and do I have access to it?

George...

Comment 10 George R. Goffe 2017-02-20 00:30:51 UTC
Created attachment 1255562 [details]
flat file of stack trace edited from /var/log/messages

Comment 11 Igor Gnatenko 2017-02-20 08:42:41 UTC
(In reply to George R. Goffe from comment #9)
> Igor,
> 
> I don't understand how you guys can close this bug because I'm STILL having
> the problem. 

This particular bug has been fixed in Rawhide. F24 and F25 versions of DNF getting only security fixes.

Comment 12 George R. Goffe 2017-02-20 08:57:01 UTC
Igor,

I think this system is up to date yet I'm getting LOTS of segfaults.

Am I doing something wrong? How would you suggest I proceed. Is there a "special" rpm for DNF et. al. that I should install first?

Thanks for your response and help.

George...