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 2
Date: Tue, 15 Jul 2008 22:18:35 -1000 [thread overview]
Message-ID: <487DAEDB.3020007@gmail.com> (raw)
Some iso9660 images contain files with rockridge data that is either
incorrect or
incompletely parsed. Prior to commit
f2966632a134e865db3c819346a1dc7d96e05309,
(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>
---
Pekka Enberg correctly pointed out that there was a similar change made to
parse_rock_ridge_inode_internal() that should also be reverted. Please
ignore
my previous patch, and use this patch instead. Thanks Pekka!
--- linux-2.6.26/fs/isofs/rock.c.orig 2008-07-13 11:51:29.000000000 -1000
+++ linux-2.6.26/fs/isofs/rock.c 2008-07-15 21:52:43.000000000 -1000
@@ -209,6 +209,9 @@ 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 +219,9 @@ repeat:
goto eio;
rs.chr += rr->len;
rs.len -= rr->len;
+ /* As above, ignore 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 +311,9 @@ 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 +321,9 @@ repeat:
goto eio;
rs.chr += rr->len;
rs.len -= rr->len;
+ /* As above, ignore 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 */
next reply other threads:[~2008-07-16 8:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-16 8:18 Adam Greenblatt [this message]
2008-07-16 8:23 ` Pekka Enberg
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=487DAEDB.3020007@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
all inboxes | Powered by JetHome®