Bug 538218 - Format string error in python/rpmps-py.c:rpmps_append?
Summary: Format string error in python/rpmps-py.c:rpmps_append?
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-17 23:26 UTC by Dave Malcolm
Modified: 2009-11-20 10:23 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-11-20 10:23:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Dave Malcolm 2009-11-17 23:26:48 UTC
Description of problem:
The function "rpmps_append" has this code:
    char *pkgNEVR, *altNEVR, *str1;
    unsigned long ulong1;
    int ignoreProblem;
    rpmProblemType type;
    fnpyKey key;

    if (!PyArg_ParseTuple(value, "ssOiisN:rpmps value tuple",
			&pkgNEVR, &altNEVR, &key,
			&type, &ignoreProblem, &str1,
			&ulong1))

The final parameter, &ulong1, is thus an unsigned long*

However the conversion code 'N' doesn't seem to be a supported format code; 'k' is the correct format code for extracting unsigned long values; see http://docs.python.org/c-api/arg.html

Is this a supported API?

[david@brick check-cpython]$ python
Python 2.6.4 (r264:75706, Oct 29 2009, 22:44:06) 
[GCC 4.4.1 20090725 (Red Hat 4.4.1-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import rpm
>>> ps = rpm.ps()
>>> ps.append()
Segmentation fault

Found using my static checker tool:
http://dmalcolm.livejournal.com/3689.html

Version-Release number of selected component (if applicable):
at commit 16f9d7f4dcce8edc6458cd94ee0c7afda2c5dece ; not sure how to post this in the upstream tracker at rpm.org.

Comment 1 Panu Matilainen 2009-11-18 07:24:38 UTC
Heh, the invalid 'N' conversion has been there since 2004 and you're the first one to notice. I guess it's safe to say nobody uses the interface... might as well just remove it.

Thanks for spotting that.

Comment 2 Panu Matilainen 2009-11-20 10:23:19 UTC
"Fixed" upstream now, by killing the broken (and useless) interface.


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