pld rpm 5.4.17

[Jakub Bogusz]

On Thu, Feb 23, 2017 at 07:15:22PM -0500, Jeffrey Johnson wrote:
> 
> > On Feb 23, 2017, at 3:36 PM, Jakub Bogusz <qboosh at pld-linux.org> wrote:
> > 
> > On Thu, Feb 23, 2017 at 01:43:14PM -0500, Jeffrey Johnson wrote:
> >> This one is left though:
> >> 
> >>> error: db3: header #187105280 cannot be loaded -- skipping.
> >>> error: db3: header #4127850496 cannot be loaded -- skipping.
> >> 
> >> How to check what these "headers" mean?
> >> (old, unsupported keys? some old packages with missing fields which are
> >> now required?)
> >> The error message is printed on a headerCopyLoad() failure.
> >> 
> >> The failure is usually an indication of header damage of some sort, not missing fields now required.
> >> 
> >> The numbers  are  primary keys into Packages printed in in decimal.
> >> 
> >> The values appear to be in the wrong-endian order when converted to hex
> >> 	0xB270000
> >> 	0xF60A0000
> >> 
> >> You can try finding the header by doing, say, rpm -q ???querybynumber 0xB270000
> >> (or its reverse: its unclear what order).
> > 
> > Same result for bigger values, no result after swapping bytes:
> > 
> > -bash-4.4# rpm -q --querybynumber 0xF60A0000
> > error: rpmdb: header #4127850496 cannot be loaded -- skipping.
> > -bash-4.4# rpm -q --querybynumber 0x00000AF6
> > -bash-4.4# rpm -q --querybynumber 0xB270000
> > error: rpmdb: header #187105280 cannot be loaded -- skipping.
> > -bash-4.4# rpm -q --querybynumber 0x0000270B
> > -bash-4.4#
> > 
> 
> So at least simply reproducible with ???querybynumber ;-)
> 
> If you just need a fix, db_dump will give you {KEY, VALUE} pairs in hex.
> Find the 2 {KEY,VALUES} and delete the 2 occurrences of 2 lines of hex in a text editor.
> Feed the result to db_load to recreate Packages.
> rpm ???rebuild will recreate the indices.

I investigated these two entries. They doesn't seem to be invalid, but
are not accepted after this change:

http://rpm5.org/cvs/filediff?f=rpm/rpmdb/header.c&v1=1.198.2.23&v2=1.198.2.24

more precisely, this part:

-/*@=sizeoftype@*/
-               rpmuint32_t * stei = (rpmuint32_t *)
-                       memcpy(alloca(nb), dataStart + off, nb);
+               /* XXX copy to fix alignment problems */
+                rpmuint32_t * stei = (rpmuint32_t *)
+                          memcpy(alloca(nb), dataStart + off, nb);
+               if ((off + nb) > dl)
+                   goto errxit;
                rdl = (rpmuint32_t)-ntohl(stei[2]);     /* negative offset */
-assert((rpmint32_t)rdl >= 0);  /* XXX insurance */
-               ril = (rpmuint32_t)(rdl/sizeof(*pe));
-               if (hdrchkTags(ril) || hdrchkData(rdl))
+               if (rdl < REGION_TAG_COUNT || rdl > (rpmuint32_t)(off+nb))
                    goto errxit;

(nb. IMO "if ((off + nb) > dl)" check should be done before memcpy...)

1) package #0xB270000 the first entry of header is:
0000003f 00000007 00000280 00000010
it points to data:
dataStart+0280  0000003f 00000007 fffffca0 00000010
so rdl=0x360, which is bigger than off+nb (0x280+0x10)
but AFAICS rdl is pointer inside header part, not data...

2) similarly, package #0xF60A0000 has first header entry:
0000003f 00000007 00000378 00000010
which points to data:

dataStart+0378 0000003f 00000007 fffffc70 00000010
and rdl=0x390 > 0x378+0x10

The rest of packages I've got installed seem to have longer data in
"immutable" part and pass this check.


-- 
Jakub Bogusz    http://qboosh.pl/