Skip to contentSkip to conversation

e2fsprogs: allow 0-length xattr values in e2fsck

PATCH Applied Eric Sandeen 2 participants 3 messages Apr 7, 2013 – Apr 25, 2013

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 e2fsprogs: allow 0-length xattr values in e2fsck

e2fsck thinks that this:

# touch mnt/testfile1
# setfattr -n "user.test" mnt/testfile1

results in a filesystem with corruption:

Pass 1: Checking inodes, blocks, and sizes
Extended attribute in inode 12 has a value size (0) which is invalid Clear? yes

but as far as I can tell, there is absolutely nothing wrong with a 0-length value on an extended attribute. Just remove the check.

Addresses-Red-Hat-Bugzilla: #557959

---

Strange that this has been in e2fsck since 2005; apologies to David in particular for not addressing the bug he filed much sooner, I had assumed that this was some strange corruption, not a simple logic error / change.

e2fsck/pass1.c +1 -1
index a20b57b..94df36d 100644
@@ -307,7 +307,7 @@ static void check_ea_in_inode(e2fsck_t ctx, struct problem_context *pctx)
 		remain -= EXT2_EXT_ATTR_SIZE(entry->e_name_len);
 
 		/* check value size */
-		if (entry->e_value_size == 0 || entry->e_value_size > remain) {
+		if (entry->e_value_size > remain) {
 			pctx->num = entry->e_value_size;
 			problem = PR_1_ATTR_VALUE_SIZE;
 			goto fix;
#1 lore raw
Quoted 11 lines · Eric Sandeen

e2fsck thinks that this:

# touch mnt/testfile1
# setfattr -n "user.test" mnt/testfile1

results in a filesystem with corruption:

Pass 1: Checking inodes, blocks, and sizes
Extended attribute in inode 12 has a value size (0) which is invalid Clear? yes

Quoted 7 lines

but as far as I can tell, there is absolutely nothing wrong with a 0-length value on an extended attribute. Just remove the check.

Addresses-Red-Hat-Bugzilla: #557959

Ted, just a ping on this. I know there's been a lot going on,so wasn't sure if you missed it, or if it's just saved for later.

Thanks,
-Eric

Quoted 26 lines

---

Strange that this has been in e2fsck since 2005; apologies to David in particular for not addressing the bug he filed much sooner, I had assumed that this was some strange corruption, not a simple logic error / change.

e2fsck/pass1.c +1 -2
index a20b57b..94df36d 100644
@@ -307,7 +307,7 @@ static void check_ea_in_inode(e2fsck_t ctx, struct problem_context *pctx)
 		remain -= EXT2_EXT_ATTR_SIZE(entry->e_name_len);
 
 		/* check value size */
-		if (entry->e_value_size == 0 || entry->e_value_size > remain) {
+		if (entry->e_value_size > remain) {
 			pctx->num = entry->e_value_size;
 			problem = PR_1_ATTR_VALUE_SIZE;
 			goto fix;
 
--

To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw
In reply to Eric Sandeen
Quoted 11 lines · Eric Sandeen

e2fsck thinks that this:

# touch mnt/testfile1
# setfattr -n "user.test" mnt/testfile1

results in a filesystem with corruption:

Pass 1: Checking inodes, blocks, and sizes
Extended attribute in inode 12 has a value size (0) which is invalid Clear? yes

Quoted 7 lines

but as far as I can tell, there is absolutely nothing wrong with a 0-length value on an extended attribute. Just remove the check.

Addresses-Red-Hat-Bugzilla: #557959

Thanks, applied.

It turns out that 0-length values applied for xattrs stored in external xattr blocks. 0-length xattrs were only only getting prohibited for in-inode xattrs.

- Ted