Skip to contentSkip to conversation

bcache: fix BUG_ON due to integer overflow with GC_SECTORS_USED

PATCH In review Darrick J. Wong 3 participants 4 messages Feb 11, 2014 – Feb 12, 2014 bcache (block layer cache)

lore
Share & tools
lore

Darrick J. Wong

author
#0 lore raw

PATCH 1/1 bcache: fix BUG_ON due to integer overflow with GC_SECTORS_USED

The BUG_ON at the end of __bch_btree_mark_key can be triggered due to an integer overflow error:

BITMASK(GC_SECTORS_USED, struct bucket, gc_mark, 2, 13);
...
SET_GC_SECTORS_USED(g, min_t(unsigned,

	     GC_SECTORS_USED(g) + KEY_SIZE(k),
	     (1 << 14) - 1));

BUG_ON(!GC_SECTORS_USED(g));

In bcache.h, the SECTORS_USED bitfield is defined to be 13 bits wide. While the SET_ code tries to ensure that the field doesn't overflow by clamping it to (1<<14)-1 == 16383, this is incorrect because 16383 requires 14 bits. Therefore, if GC_SECTORS_USED() + KEY_SIZE() = 8192, the SET_ statement tries to store 8192 into a 13-bit field. In a 13-bit field, 8192 becomes zero, thus triggering the BUG_ON.

Therefore, create a field width constant and a max value constant, and use those to create the bitfield and check the inputs to SET_GC_SECTORS_USED. Arguably the BITMASK() template ought to have BUG_ON checks for too-large values, but that's a separate patch.

Signed-off-by Darrick J. Wong <[email protected]>
Signed-off-by Kent Overstreet <[email protected]>

---
Greg, stable team et. all - can you apply this asap to 3.13? It hasn't hit Linus's tree yet (it's on its way via Jens), but multiple users are hitting this BUG_ON() and the fix has been tested.

 drivers/md/bcache/bcache.h | 4 +++-
 drivers/md/bcache/btree.c  | 2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)
drivers/md/bcache/bcache.h +3 -1
index 0c707e4f4e..a4c7306ff4 100644
@@ -210,7 +210,9 @@ BITMASK(GC_MARK,	 struct bucket, gc_mark, 0, 2);
 #define GC_MARK_RECLAIMABLE	0
 #define GC_MARK_DIRTY		1
 #define GC_MARK_METADATA	2
-BITMASK(GC_SECTORS_USED, struct bucket, gc_mark, 2, 13);
+#define GC_SECTORS_USED_SIZE	13
+#define MAX_GC_SECTORS_USED	(~(~0ULL << GC_SECTORS_USED_SIZE))
+BITMASK(GC_SECTORS_USED, struct bucket, gc_mark, 2, GC_SECTORS_USED_SIZE);
 BITMASK(GC_MOVE, struct bucket, gc_mark, 15, 1);
 
 #include "journal.h"
drivers/md/bcache/btree.c +1 -1
index 98cc0a810a..7d421180b6 100644
@@ -1167,7 +1167,7 @@ uint8_t __bch_btree_mark_key(struct cache_set *c, int level, struct bkey *k)
 		/* guard against overflow */
 		SET_GC_SECTORS_USED(g, min_t(unsigned,
 					     GC_SECTORS_USED(g) + KEY_SIZE(k),
-					     (1 << 14) - 1));
+					     MAX_GC_SECTORS_USED));
 
 		BUG_ON(!GC_SECTORS_USED(g));
 	}
Signature · 1 line
1.9.0.rc3
#1 lore raw
Quoted 22 lines · Darrick J. Wong

The BUG_ON at the end of __bch_btree_mark_key can be triggered due to an integer overflow error:

BITMASK(GC_SECTORS_USED, struct bucket, gc_mark, 2, 13);
...
SET_GC_SECTORS_USED(g, min_t(unsigned,

	     GC_SECTORS_USED(g) + KEY_SIZE(k),
	     (1 << 14) - 1));

BUG_ON(!GC_SECTORS_USED(g));

In bcache.h, the SECTORS_USED bitfield is defined to be 13 bits wide. While the SET_ code tries to ensure that the field doesn't overflow by clamping it to (1<<14)-1 == 16383, this is incorrect because 16383 requires 14 bits. Therefore, if GC_SECTORS_USED() + KEY_SIZE() = 8192, the SET_ statement tries to store 8192 into a 13-bit field. In a 13-bit field, 8192 becomes zero, thus triggering the BUG_ON.

Therefore, create a field width constant and a max value constant, and use those to create the bitfield and check the inputs to SET_GC_SECTORS_USED. Arguably the BITMASK() template ought to have BUG_ON checks for too-large values, but that's a separate patch.

Quoted 6 lines
Signed-off-by Darrick J. Wong <[email protected]>
Signed-off-by Kent Overstreet <[email protected]>

---
Greg, stable team et. all - can you apply this asap to 3.13? It hasn't hit Linus's tree yet (it's on its way via Jens), but multiple users are hitting this BUG_ON() and the fix has been tested.

Think about what you just wrote.

Then go read Documentation/stable_kernel_rules.txt.

You should know better...

greg k-h

author
#2 lore raw
Quoted 30 lines · Greg KH
Quoted 22 lines · Darrick J. Wong

The BUG_ON at the end of __bch_btree_mark_key can be triggered due to an integer overflow error:

BITMASK(GC_SECTORS_USED, struct bucket, gc_mark, 2, 13);
...
SET_GC_SECTORS_USED(g, min_t(unsigned,

	     GC_SECTORS_USED(g) + KEY_SIZE(k),
	     (1 << 14) - 1));

BUG_ON(!GC_SECTORS_USED(g));

In bcache.h, the SECTORS_USED bitfield is defined to be 13 bits wide. While the SET_ code tries to ensure that the field doesn't overflow by clamping it to (1<<14)-1 == 16383, this is incorrect because 16383 requires 14 bits. Therefore, if GC_SECTORS_USED() + KEY_SIZE() = 8192, the SET_ statement tries to store 8192 into a 13-bit field. In a 13-bit field, 8192 becomes zero, thus triggering the BUG_ON.

Therefore, create a field width constant and a max value constant, and use those to create the bitfield and check the inputs to SET_GC_SECTORS_USED. Arguably the BITMASK() template ought to have BUG_ON checks for too-large values, but that's a separate patch.

Quoted 6 lines
Signed-off-by Darrick J. Wong <[email protected]>
Signed-off-by Kent Overstreet <[email protected]>

---
Greg, stable team et. all - can you apply this asap to 3.13? It hasn't hit Linus's tree yet (it's on its way via Jens), but multiple users are hitting this BUG_ON() and the fix has been tested.

Quoted 5 lines

Think about what you just wrote.

Then go read Documentation/stable_kernel_rules.txt.

You should know better...

I figured if any patch qualified for skipping ahead this one would - and it always takes awhile for stuff to make it through Jens, but ah well.

It's 947174476701fbc84ea8c7ec9664270f9d80b076, currently in Jens' for-linus tree, I'll ping you again when I see it go in since I forgot to add the stable tag to the patch.

#3 lore raw
Quoted 35 lines · Kent Overstreet
Quoted 34 lines · Greg KH
Quoted 22 lines · Darrick J. Wong

The BUG_ON at the end of __bch_btree_mark_key can be triggered due to an integer overflow error:

BITMASK(GC_SECTORS_USED, struct bucket, gc_mark, 2, 13);
...
SET_GC_SECTORS_USED(g, min_t(unsigned,

	     GC_SECTORS_USED(g) + KEY_SIZE(k),
	     (1 << 14) - 1));

BUG_ON(!GC_SECTORS_USED(g));

In bcache.h, the SECTORS_USED bitfield is defined to be 13 bits wide. While the SET_ code tries to ensure that the field doesn't overflow by clamping it to (1<<14)-1 == 16383, this is incorrect because 16383 requires 14 bits. Therefore, if GC_SECTORS_USED() + KEY_SIZE() = 8192, the SET_ statement tries to store 8192 into a 13-bit field. In a 13-bit field, 8192 becomes zero, thus triggering the BUG_ON.

Therefore, create a field width constant and a max value constant, and use those to create the bitfield and check the inputs to SET_GC_SECTORS_USED. Arguably the BITMASK() template ought to have BUG_ON checks for too-large values, but that's a separate patch.

Quoted 6 lines
Signed-off-by Darrick J. Wong <[email protected]>
Signed-off-by Kent Overstreet <[email protected]>

---
Greg, stable team et. all - can you apply this asap to 3.13? It hasn't hit Linus's tree yet (it's on its way via Jens), but multiple users are hitting this BUG_ON() and the fix has been tested.

Think about what you just wrote.

Then go read Documentation/stable_kernel_rules.txt.

Quoted 8 lines
Quoted 1 line

You should know better...

I figured if any patch qualified for skipping ahead this one would - and it always takes awhile for stuff to make it through Jens, but ah well.

It's 947174476701fbc84ea8c7ec9664270f9d80b076, currently in Jens' for-linus tree, I'll ping you again when I see it go in since I forgot to add the stable tag to the patch.

You might want to fix the From: header as well... ;)

--D

Quoted 4 lines

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