Skip to contentSkip to conversation

certain data corruption may cause reiserfs to panic, fix.

PATCH In review Oleg Drokin 3 participants 4 messages Jan 9, 2002 – Jan 11, 2002

lore
Share & tools
lore

Oleg Drokin

author
#0 lore raw

PATCH 1/1 certain data corruption may cause reiserfs to panic, fix.

Hello!

Purpose of this patch is to catch events of corrupted ITEM_TYPE fields, and report these to user. Without this patch, accessing such items will resukt in dereferencing random memory areas in kernel, and then ooping (most probably).
Please apply.

Bye,
Oleg

include/linux/reiserfs_fs.h renamed from include/linux/reiserfs_fs.h.orig +11 -12
@@ -204,7 +204,15 @@
 #define REISERFS_VALID_FS    1
 #define REISERFS_ERROR_FS    2
 
-
+//
+// there are 5 item types currently
+//
+#define TYPE_STAT_DATA 0
+#define TYPE_INDIRECT 1
+#define TYPE_DIRECT 2
+#define TYPE_DIRENTRY 3 
+#define TYPE_MAXTYPE 3 
+#define TYPE_ANY 15 // FIXME: comment is required
 
 /***************************************************************************/
 /*                       KEY & ITEM HEAD                                   */

@@ -240,7 +248,7 @@
 {
     offset_v2_esafe_overlay tmp = *(offset_v2_esafe_overlay *)v2;
     tmp.linear = le64_to_cpu( tmp.linear );
-    return tmp.offset_v2.k_type;
+    return (tmp.offset_v2.k_type <= TYPE_MAXTYPE)?tmp.offset_v2.k_type:TYPE_ANY;
 }
  
 static inline void set_offset_v2_k_type( struct offset_v2 *v2, int type )

@@ -390,15 +398,6 @@
 #define put_block_num(p, i, v) put_unaligned(cpu_to_le32(v), (p) + (i))
 
 //
-// there are 5 item types currently
-//
-#define TYPE_STAT_DATA 0
-#define TYPE_INDIRECT 1
-#define TYPE_DIRECT 2
-#define TYPE_DIRENTRY 3 
-#define TYPE_ANY 15 // FIXME: comment is required
-
-//
 // in old version uniqueness field shows key type
 //
 #define V1_SD_UNIQUENESS 0

@@ -1365,7 +1364,7 @@
 
 extern struct item_operations stat_data_ops, indirect_ops, direct_ops, 
   direntry_ops;
-extern struct item_operations * item_ops [4];
+extern struct item_operations * item_ops [TYPE_ANY + 1];
 
 #define op_bytes_number(ih,bsize)                    item_ops[le_ih_k_type (ih)]->bytes_number (ih, bsize)
 #define op_is_left_mergeable(key,bsize)              item_ops[le_key_k_type (le_key_version (key), key)]->is_left_mergeable (key, bsize)
fs/reiserfs/stree.c renamed from fs/reiserfs/stree.c.orig +4 -0
@@ -524,6 +524,10 @@
     ih = (struct item_head *)(buf + BLKH_SIZE);
     prev_location = blocksize;
     for (i = 0; i < nr; i ++, ih ++) {
+	if ( le_ih_k_type(ih) == TYPE_ANY) {
+	    reiserfs_warning ("is_leaf: wrong item type for item %h\n",ih);
+	    return 0;
+	}
 	if (ih_location (ih) >= blocksize || ih_location (ih) < IH_SIZE * nr) {
 	    reiserfs_warning ("is_leaf: item location seems wrong: %h\n", ih);
 	    return 0;
fs/reiserfs/item_ops.c renamed from fs/reiserfs/item_ops.c.orig +95 -2

112 lines not on this page · raw message

#1 lore raw
Quoted 6 lines · Oleg Drokin

Hello!

Purpose of this patch is to catch events of corrupted ITEM_TYPE fields, and report these to user. Without this patch, accessing such items will resukt in dereferencing random memory areas in kernel, and then ooping (most probably).
Please apply.

Why corruption is happening in the first place ?

#2 lore raw
Quoted 11 lines · On Wednesday, January 09, 2002 02:58:45 PM -0200 Marcelo Tosatti…
Quoted 7 lines · Oleg Drokin

Hello!

Purpose of this patch is to catch events of corrupted ITEM_TYPE fields, and report these to user. Without this patch, accessing such items will resukt in dereferencing random memory areas in kernel, and then ooping (most probably).
Please apply.

Why corruption is happening in the first place ?

Oddly, the corruption most often caught by this patch was from the early redhat gcc 2.96.

-chris

author
#3 lore raw
In reply to Oleg Drokin

Hello!

Quoted 5 lines · Marcelo Tosatti
Quoted 4 lines

Purpose of this patch is to catch events of corrupted ITEM_TYPE fields, and report these to user. Without this patch, accessing such items will resukt in dereferencing random memory areas in kernel, and then ooping (most probably).
Please apply.

Why corruption is happening in the first place ?

As Chris already pointed out, there was a problem with old gcc 2.96.
Also such corruptions might be a fault of a disk, somebody carelessly writing data to reiserfsdisk and so on. Right now it is way too easy to get reiserfs to panic by mounting specially crafted abd disk image, and this is bad, I believe, so one of the tasks I am performing is to minimalize such cases. (look at ext2 as an example goal I want to achieve some time in the future)

Bye,
Oleg