mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
To: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linus Torvalds <Linus.Torvalds@Helsinki.FI>,
	linux-kernel@vger.kernel.org
Subject: [PATCH] NTFS comment expanded, small fix.
Date: Sun, 15 Apr 2001 14:53:58 +0200 (CEST)	[thread overview]
Message-ID: <200104151253.OAA27090@abraracourcix.bitwizard.nl> (raw)


Hi all,

I am studying an NTFS problem, and came across the NTFS fixup mechanism. 

It took me much too long to understand the fixup mechanism, even though
a comment tried to explain it. So I rewrote the comment. 

Also, the "start" value that is read from the record, could be much 
larger than expected, which could lead to accessing random data. The
fixup should fail then, and this is also patched below. 

Patch attached. 

				Roger. 

--------------------------------------------------------------------

diff -ur linux-2.4.3.clean/fs/ntfs/super.c linux-2.4.3.ntfs_fix/fs/ntfs/super.c
--- linux-2.4.3.clean/fs/ntfs/super.c	Sun Apr 15 14:48:05 2001
+++ linux-2.4.3.ntfs_fix/fs/ntfs/super.c	Sun Apr 15 14:47:48 2001
@@ -30,6 +30,22 @@
  * . the magic identifier is wrong
  * . the size is given and does not match the number of sectors
  * . a fixup is invalid
+ ******
+ * Somehow that comment may sound usable to the person who wrote it, but 
+ * in fact it took me over an hour to figure it out. That's not what 
+ * comments are for. So let me try to explain it: 
+ *
+ * A record contains a fixup-area. The size of this area is S+1 words,
+ * with S the number of sectors in the record. 
+ *
+ * The first word of the fixup area is a random word. 
+ * The last word of every sector should contain this random word. 
+ * The rest of the fixup area contains the original contents of that
+ * last word of each sector of the record. 
+ * the position and length of the fixup area are stored at offset 4 
+ * and 6 in the record.  
+ *
+ * Hope this helps. -- REW
  */
 int ntfs_fixup_record(ntfs_volume *vol, char *record, char *magic, int size)
 {
@@ -42,6 +58,8 @@
 	count=NTFS_GETU16(record+6);
 	count--;
 	if(size && vol->blocksize*count != size)
+		return 0;
+	if (start >= size) 
 		return 0;
 	fixup = NTFS_GETU16(record+start);
 	start+=2;
Only in linux-2.4.3.ntfs_fix/fs/ntfs: super.c.orig


-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

             reply	other threads:[~2001-04-15 12:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-15 12:53 Rogier Wolff [this message]
2001-04-15 17:11 Anton Altaparmakov
2001-04-15 18:16 ` Rogier Wolff
2001-04-15 20:56   ` Anton Altaparmakov
2001-04-15 22:11 ` Alan Cox
2001-04-15 23:52 ` Anton Altaparmakov
2001-04-16  0:18   ` Alan Cox

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=200104151253.OAA27090@abraracourcix.bitwizard.nl \
    --to=r.e.wolff@bitwizard.nl \
    --cc=Linus.Torvalds@Helsinki.FI \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®