From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Gary Thomas <gary@mlbassoc.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] rpm: Fix cpio 32 bit overflow issues on 64 bit inode filesystems
Date: Tue, 10 Jun 2014 17:49:44 +0100 [thread overview]
Message-ID: <1402418984.12440.321.camel@ted> (raw)
In-Reply-To: <53973577.8080902@mlbassoc.com>
On Tue, 2014-06-10 at 10:42 -0600, Gary Thomas wrote:
> On 2014-06-10 10:37, Mark Hatle wrote:
> > On 6/10/14, 11:32 AM, Richard Purdie wrote:
> >> When building on XFS filesystems, the resulting rpms can be corrupted
> >> with the same inode number being used for multiple hardlinked files.
> >> There are two fixes, one to stop rpm crashing when accessing a broken
> >> binary rpm, the other to stop generating them in the first places. Full
> >> descriptions in the patch headers.
> >>
> >> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >>
> >> diff --git a/meta/recipes-devtools/rpm/rpm/rpm-hardlink-segfault-fix.patch b/meta/recipes-devtools/rpm/rpm/rpm-hardlink-segfault-fix.patch
> >> new file mode 100644
> >> index 0000000..d49de6f
> >> --- /dev/null
> >> +++ b/meta/recipes-devtools/rpm/rpm/rpm-hardlink-segfault-fix.patch
> >> @@ -0,0 +1,43 @@
> >> +We need to sanity check that the nlink size and our linksLeft counter
> >> +do match. If an rpm is badly constucted with identical inode values
> >
> > s/constucted/constructed
> >
> >> +for multiple hardlinked files, such an rpm will overwise access memory
> >
> > s/overwise/otherwise
> >
> >> +out of array bounds and cause memory corruption and crashes.
> >> +
> >> +The fix is to add in the sanity check and exit if bad circumstances
> >> +are found. We need to fix the caller to check the return code too.
> >> +
> >> +RP 10/6/1024
> >
> > 2014?
>
> Perhaps even an ISO date (2014-06-10) since that's what's used everywhere
> else (and it's not October yet, at least not on this side of the pond)
I do try and use ISO dates in patches after a comment from you a while
back. On this occasion lets just say it wasn't the top thing on my mind
(nor was spelling, clearly :/).
I've been staring at debugging this issue for 48 hours and there is some
pressure on for getting it fixed and several things unblocked. I wasn't
feeling particularly well when I started and am not much better now so
let me just say thanks for the fixes and leave this there :)
Cheers,
Richard
prev parent reply other threads:[~2014-06-10 16:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 16:32 [PATCH] rpm: Fix cpio 32 bit overflow issues on 64 bit inode filesystems Richard Purdie
2014-06-10 16:37 ` Mark Hatle
2014-06-10 16:42 ` Gary Thomas
2014-06-10 16:49 ` Richard Purdie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1402418984.12440.321.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=gary@mlbassoc.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.