public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adam Greenblatt <adam.greenblatt@gmail.com>
To: penberg@cs.helsinki.fi, akpm@linux-foundation.org, jack@ucw.cz,
	linux-kernel@vger.kernel.org
Subject: [PATCH 2.6.26] isofs: fix minor filesystem corruption, take 3
Date: Tue, 15 Jul 2008 23:05:18 -1000	[thread overview]
Message-ID: <487DB9CE.3070906@gmail.com> (raw)

Some iso9660 images contain files with rockridge data that is either 
incorrect or
incompletely parsed.  Prior to commit 
f2966632a134e865db3c819346a1dc7d96e05309
("[PATCH] rock: handle directory overflows") (included with kernel 
2.6.13) the
kernel ignored the rockridge data for these files, while still allowing 
the files
to be accessed under their non-rockridge names.  That commit 
inadvertently changed
things so that files with invalid rockridge data could not be accessed 
at all.
(I ran across the problem when comparing some old CDs with hard disk 
copies I had
made long ago under kernel 2.4: a few of the files on the hard disk 
copies were no
longer visible on the CDs.)

This change reverts to the pre-2.6.13 behavior.

Signed-off-by: Adam Greenblatt <adam.greenblatt@gmail.com>
---
This patch is functionally identical to the previous one, but correctly 
formats
the comments and commit description.  Please ignore my previous patches, 
and use
this patch instead.  Thanks!
--- linux-2.6.26/fs/isofs/rock.c.orig   2008-07-15 22:49:00.000000000 -1000
+++ linux-2.6.26/fs/isofs/rock.c        2008-07-15 22:50:06.000000000 -1000
@@ -209,6 +209,11 @@ repeat:
 
        while (rs.len > 2) { /* There may be one byte for padding 
somewhere */
                rr = (struct rock_ridge *)rs.chr;
+               /*
+                * Ignore rock ridge info if rr->len is out of range, but
+                * don't return -EIO because that would make the file
+                * invisible.
+                */
                if (rr->len < 3)
                        goto out;       /* Something got screwed up here */
                sig = isonum_721(rs.chr);
@@ -216,8 +221,12 @@ repeat:
                        goto eio;
                rs.chr += rr->len;
                rs.len -= rr->len;
+               /*
+                * As above, just ignore the rock ridge info if rr->len
+                * is bogus.
+                */
                if (rs.len < 0)
-                       goto eio;       /* corrupted isofs */
+                       goto out;       /* Something got screwed up here */
 
                switch (sig) {
                case SIG('R', 'R'):
@@ -307,6 +316,11 @@ parse_rock_ridge_inode_internal(struct i
 repeat:
        while (rs.len > 2) { /* There may be one byte for padding 
somewhere */
                rr = (struct rock_ridge *)rs.chr;
+               /*
+                * Ignore rock ridge info if rr->len is out of range, but
+                * don't return -EIO because that would make the file
+                * invisible.
+                */
                if (rr->len < 3)
                        goto out;       /* Something got screwed up here */
                sig = isonum_721(rs.chr);
@@ -314,8 +328,12 @@ repeat:
                        goto eio;
                rs.chr += rr->len;
                rs.len -= rr->len;
+               /*
+                * As above, just ignore the rock ridge info if rr->len
+                * is bogus.
+                */
                if (rs.len < 0)
-                       goto eio;       /* corrupted isofs */
+                       goto out;       /* Something got screwed up here */
 
                switch (sig) {
 #ifndef CONFIG_ZISOFS          /* No flag for SF or ZF */


                 reply	other threads:[~2008-07-16  9:05 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=487DB9CE.3070906@gmail.com \
    --to=adam.greenblatt@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=jack@ucw.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    /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