Openembedded Core Discussions
 help / color / mirror / Atom feed
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



      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox