Bug 904818 - rpmbuild crashes with double free if wildcards are used with %caps in spec file
Summary: rpmbuild crashes with double free if wildcards are used with %caps in spec file
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: rpm
Version: 6.5
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: Karel Srot
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-27 17:54 UTC by Paul Donohue
Modified: 2013-12-13 23:54 UTC (History)
6 users (show)

(edit)
Clone Of:
: 1002089 (view as bug list)
(edit)
Last Closed: 2013-11-21 21:39:43 UTC


Attachments (Terms of Use)
patch to correct the problem (375 bytes, patch)
2013-01-27 17:54 UTC, Paul Donohue
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1665 normal SHIPPED_LIVE rpm bug fix update 2013-11-20 21:53:00 UTC
Red Hat Bugzilla 877512 None None None Never
Red Hat Bugzilla 956190 None None None Never

Internal Trackers: 956190

Description Paul Donohue 2013-01-27 17:54:09 UTC
Created attachment 688536 [details]
patch to correct the problem

In a spec file, under a %files section, add a %caps tag that uses a wildcard:
%caps(cap_net_bind_service+ep) bin/*

Then run `rpmbuild -ba SPECS/pkg.spec`

rpmbuild reliably crashes:
*** glibc detected *** rpmbuild: double free or corruption (fasttop): 0x0000000000691d30 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x75916)[0x7f6cdf11f916]
/usr/lib64/librpmio.so.1(rfree+0x9)[0x7f6ce146c439]
/usr/lib64/librpmbuild.so.1(+0xa4a0)[0x7f6ce1b164a0]
/usr/lib64/librpmbuild.so.1(+0xdeb9)[0x7f6ce1b19eb9]
/usr/lib64/librpmbuild.so.1(processBinaryFiles+0xd7)[0x7f6ce1b1aeb7]
/usr/lib64/librpmbuild.so.1(buildSpec+0x30e)[0x7f6ce1b1548e]
rpmbuild[0x40309a]
rpmbuild[0x403330]
rpmbuild[0x403de8]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f6cdf0c8cdd]
rpmbuild[0x402799]

(gdb) where
#0  0x00007f6cdf0dc8a5 in raise () from /lib64/libc.so.6
#1  0x00007f6cdf0de085 in abort () from /lib64/libc.so.6
#2  0x00007f6cdf119fe7 in __libc_message () from /lib64/libc.so.6
#3  0x00007f6cdf11f916 in malloc_printerr () from /lib64/libc.so.6
#4  0x00007f6ce146c439 in rfree (ptr=<value optimized out>) at rpmmalloc.c:78
#5  0x00007f6ce1b164a0 in freeFileList (fileList=0x6cedb0, count=<value optimized out>)
    at files.c:1350
#6  0x00007f6ce1b19eb9 in processPackageFiles (spec=<value optimized out>,_
    pkg=<value optimized out>, installSpecialDoc=4, test=0) at files.c:1995
#7  0x00007f6ce1b1aeb7 in processBinaryFiles (spec=0x6439e0, installSpecialDoc=4, test=0)
    at files.c:2278
#8  0x00007f6ce1b1548e in buildSpec (ts=0x643600, spec=0x6439e0, what=223, test=0) at build.c:257
#9  0x000000000040309a in buildForTarget (ts=0x643600, arg=<value optimized out>,_
    ba=0x7f6ce1d37b80) at build.c:278
#10 0x0000000000403330 in build (ts=0x643600, arg=0x7fff315a8753 "SPECS/httpd.spec",_
    ba=0x7f6ce1d37b80, rcfile=0x0) at build.c:312
#11 0x0000000000403de8 in main (argc=3, argv=<value optimized out>) at rpmqv.c:694

The problem is that a pointer to the caps definition is copied into the data structure for each file it applies to.  freeFileList then tries to free this pointer repeatedly.

The attached patch corrects the problem by making a copy of the caps data for each file it applies to.

Comment 2 David Zambonini 2013-02-08 17:28:42 UTC
I thought that I should add that this bug is not limited to wildcards, and appears to a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=877512 (which is fixed in rawhide).

Comment 3 RHEL Product and Program Management 2013-07-25 21:10:36 UTC
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

Comment 10 errata-xmlrpc 2013-11-21 21:39:43 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1665.html


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