Mailing List Archive

btrfs size overflow bug since 4.2.6-hardened-r6
I'm still facing a bug with btrfs that
occurs since 4.2.6-hardened-r6 till 4.4.2.

An similar bug has been patched already
https://patchwork.kernel.org/patch/7582351/

Is someone able to reproduce this?

Thx!

my config:

https://binarysignals.net/pub/linux-4.2.6-hardened-r5.config
https://binarysignals.net/pub/emerge--info_e10.txt

dmesg:

Feb 20 17:21:22 e10 kernel: PAX: size overflow detected in function
btrfs_extent_item_to_extent_map fs/btrfs/file-item.c:913 cicus.463_134
min, count: 150, decl: orig_start; num: 0; context: extent_map;
Feb 20 17:21:22 e10 kernel: CPU: 0 PID: 4709 Comm: evolution-addre Not
tainted 4.4.2-hardened #1
Feb 20 17:21:22 e10 kernel: Hardware name: Dell Inc. Latitude E4200
/0XRV1H, BIOS A24 06/04/2013
Feb 20 17:21:22 e10 kernel: ffff880100000002 c3eced83898a9252
0000000000000000 0000000000000391
Feb 20 17:21:22 e10 kernel: ffffc90005893630 ffffffffa26152bb
ffffffffa9124d70 c3eced83898a9252
Feb 20 17:21:22 e10 kernel: ffffffffa9124d70 ffffc90005893660
ffffffffa2241e6e ffff8800baa0d2f8
Feb 20 17:21:22 e10 kernel: Call Trace:
Feb 20 17:21:22 e10 kernel: [<ffffffffa26152bb>] dump_stack+0x57/0x8c
Feb 20 17:21:22 e10 kernel: [<ffffffffa2241e6e>]
report_size_overflow+0x6e/0x80
Feb 20 17:21:22 e10 kernel: [<ffffffffa24c2f68>]
btrfs_extent_item_to_extent_map+0x458/0x490
Feb 20 17:21:22 e10 kernel: [<ffffffffa24d4a86>]
btrfs_get_extent+0xbe6/0xdb0
Feb 20 17:21:22 e10 kernel: [<ffffffffa24f9291>] ?
submit_extent_page+0x101/0x250
Feb 20 17:21:22 e10 kernel: [<ffffffffa24fa305>]
__do_readpage+0x2b5/0xe50
Feb 20 17:21:22 e10 kernel: [<ffffffffa24fbcf0>] ?
btrfs_create_repair_bio+0x1a0/0x1a0
Feb 20 17:21:22 e10 kernel: [<ffffffffa24d3ea0>] ?
btrfs_direct_IO+0x530/0x530
Feb 20 17:21:22 e10 kernel: [<ffffffffa24fb3d0>]
__extent_readpages.constprop.44+0x310/0x350
Feb 20 17:21:22 e10 kernel: [<ffffffffa24d3ea0>] ?
btrfs_direct_IO+0x530/0x530
Feb 20 17:21:22 e10 kernel: [<ffffffffa24fd1e4>]
extent_readpages+0x1e4/0x1f0
Feb 20 17:21:22 e10 kernel: [<ffffffffa24d3ea0>] ?
btrfs_direct_IO+0x530/0x530
Feb 20 17:21:22 e10 kernel: [<ffffffffa2212cd9>] ?
alloc_pages_current+0x89/0x110
Feb 20 17:21:22 e10 kernel: [<ffffffffa24d1df2>]
btrfs_readpages+0x32/0x40
Feb 20 17:21:22 e10 kernel: [<ffffffffa21d18b1>]
__do_page_cache_readahead+0x1d1/0x250
Feb 20 17:21:22 e10 kernel: [<ffffffffa21d1a11>]
ondemand_readahead+0xe1/0x2e0
Feb 20 17:21:22 e10 kernel: [<ffffffffa21d1dc6>]
page_cache_sync_readahead+0x46/0x70
Feb 20 17:21:22 e10 kernel: [<ffffffffa21c4e43>]
generic_file_read_iter+0x633/0x7c0
Feb 20 17:21:22 e10 kernel: [<ffffffffa223926b>] __vfs_read+0x10b/0x140
Feb 20 17:21:22 e10 kernel: [<ffffffffa2239e83>] vfs_read+0xc3/0x240
Feb 20 17:21:22 e10 kernel: [<ffffffffa225e8cd>] ?
__fget_light+0x2d/0x70
Feb 20 17:21:22 e10 kernel: [<ffffffffa223b453>] SyS_pread64+0xa3/0xc0
Feb 20 17:21:22 e10 kernel: [<ffffffffa2d4a999>]
entry_SYSCALL_64_fastpath+0x12/0x83
Feb 20 17:21:22 e10 kernel: ------------[ cut here ]------------
Re: btrfs size overflow bug since 4.2.6-hardened-r6 [ In reply to ]
I've experienced this bug, but I can no longer reproduce it using recent
kernels (4.3.5-hardened-r2 or 4.4.2-hardened).

BTW, this is the patch you are looking for:
diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
index 6a98bdd..fed3da6 100644
--- a/fs/btrfs/extent_map.c
+++ b/fs/btrfs/extent_map.c
@@ -235,7 +235,9 @@ static void try_merge_map(struct extent_map_tree
*tree, struct extent_map *em)
em->start = merge->start;
em->orig_start = merge->orig_start;
em->len += merge->len;
- em->block_len += merge->block_len;
+ if (em->block_start != EXTENT_MAP_HOLE &&
+ em->block_start != EXTENT_MAP_INLINE)
+ em->block_len += merge->block_len;
em->block_start = merge->block_start;
em->mod_len = (em->mod_len + em->mod_start) -
merge->mod_start;
em->mod_start = merge->mod_start;
@@ -252,7 +254,9 @@ static void try_merge_map(struct extent_map_tree
*tree, struct extent_map *em)
merge = rb_entry(rb, struct extent_map, rb_node);
if (rb && mergable_maps(em, merge)) {
em->len += merge->len;
- em->block_len += merge->block_len;
+ if (em->block_start != EXTENT_MAP_HOLE &&
+ em->block_start != EXTENT_MAP_INLINE)
+ em->block_len += merge->block_len;
rb_erase(&merge->rb_node, &tree->map);
RB_CLEAR_NODE(&merge->rb_node);
em->mod_len = (merge->mod_start + merge->mod_len) -
em->mod_start;

This patch has been recently included - if I'm correct.

In the mean time: do not enable quota groups, because it causes an error
with hardened kernels.
https://forums.grsecurity.net/viewtopic.php?f=3&t=4392

BR: Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2016.Március 3.(Cs) 17:44 időpontban ingo.schmitt@binarysignals.net ezt írta:
> I'm still facing a bug with btrfs that
> occurs since 4.2.6-hardened-r6 till 4.4.2.
>
> An similar bug has been patched already
> https://patchwork.kernel.org/patch/7582351/
>
> Is someone able to reproduce this?
>
> Thx!
>
> my config:
>
> https://binarysignals.net/pub/linux-4.2.6-hardened-r5.config
> https://binarysignals.net/pub/emerge--info_e10.txt
>
> dmesg:
>
> Feb 20 17:21:22 e10 kernel: PAX: size overflow detected in function
> btrfs_extent_item_to_extent_map fs/btrfs/file-item.c:913 cicus.463_134
> min, count: 150, decl: orig_start; num: 0; context: extent_map;
> Feb 20 17:21:22 e10 kernel: CPU: 0 PID: 4709 Comm: evolution-addre Not
> tainted 4.4.2-hardened #1
> Feb 20 17:21:22 e10 kernel: Hardware name: Dell Inc. Latitude E4200
> /0XRV1H, BIOS A24 06/04/2013
> Feb 20 17:21:22 e10 kernel: ffff880100000002 c3eced83898a9252
> 0000000000000000 0000000000000391
> Feb 20 17:21:22 e10 kernel: ffffc90005893630 ffffffffa26152bb
> ffffffffa9124d70 c3eced83898a9252
> Feb 20 17:21:22 e10 kernel: ffffffffa9124d70 ffffc90005893660
> ffffffffa2241e6e ffff8800baa0d2f8
> Feb 20 17:21:22 e10 kernel: Call Trace:
> Feb 20 17:21:22 e10 kernel: [<ffffffffa26152bb>] dump_stack+0x57/0x8c
> Feb 20 17:21:22 e10 kernel: [<ffffffffa2241e6e>]
> report_size_overflow+0x6e/0x80
> Feb 20 17:21:22 e10 kernel: [<ffffffffa24c2f68>]
> btrfs_extent_item_to_extent_map+0x458/0x490
> Feb 20 17:21:22 e10 kernel: [<ffffffffa24d4a86>]
> btrfs_get_extent+0xbe6/0xdb0
> Feb 20 17:21:22 e10 kernel: [<ffffffffa24f9291>] ?
> submit_extent_page+0x101/0x250
> Feb 20 17:21:22 e10 kernel: [<ffffffffa24fa305>]
> __do_readpage+0x2b5/0xe50
> Feb 20 17:21:22 e10 kernel: [<ffffffffa24fbcf0>] ?
> btrfs_create_repair_bio+0x1a0/0x1a0
> Feb 20 17:21:22 e10 kernel: [<ffffffffa24d3ea0>] ?
> btrfs_direct_IO+0x530/0x530
> Feb 20 17:21:22 e10 kernel: [<ffffffffa24fb3d0>]
> __extent_readpages.constprop.44+0x310/0x350
> Feb 20 17:21:22 e10 kernel: [<ffffffffa24d3ea0>] ?
> btrfs_direct_IO+0x530/0x530
> Feb 20 17:21:22 e10 kernel: [<ffffffffa24fd1e4>]
> extent_readpages+0x1e4/0x1f0
> Feb 20 17:21:22 e10 kernel: [<ffffffffa24d3ea0>] ?
> btrfs_direct_IO+0x530/0x530
> Feb 20 17:21:22 e10 kernel: [<ffffffffa2212cd9>] ?
> alloc_pages_current+0x89/0x110
> Feb 20 17:21:22 e10 kernel: [<ffffffffa24d1df2>]
> btrfs_readpages+0x32/0x40
> Feb 20 17:21:22 e10 kernel: [<ffffffffa21d18b1>]
> __do_page_cache_readahead+0x1d1/0x250
> Feb 20 17:21:22 e10 kernel: [<ffffffffa21d1a11>]
> ondemand_readahead+0xe1/0x2e0
> Feb 20 17:21:22 e10 kernel: [<ffffffffa21d1dc6>]
> page_cache_sync_readahead+0x46/0x70
> Feb 20 17:21:22 e10 kernel: [<ffffffffa21c4e43>]
> generic_file_read_iter+0x633/0x7c0
> Feb 20 17:21:22 e10 kernel: [<ffffffffa223926b>] __vfs_read+0x10b/0x140
> Feb 20 17:21:22 e10 kernel: [<ffffffffa2239e83>] vfs_read+0xc3/0x240
> Feb 20 17:21:22 e10 kernel: [<ffffffffa225e8cd>] ?
> __fget_light+0x2d/0x70
> Feb 20 17:21:22 e10 kernel: [<ffffffffa223b453>] SyS_pread64+0xa3/0xc0
> Feb 20 17:21:22 e10 kernel: [<ffffffffa2d4a999>]
> entry_SYSCALL_64_fastpath+0x12/0x83
> Feb 20 17:21:22 e10 kernel: ------------[ cut here ]------------
>
>
Re: btrfs size overflow bug since 4.2.6-hardened-r6 [ In reply to ]
On 3 Mar 2016 at 17:44, ingo.schmitt@binarysignals.net wrote:

> I'm still facing a bug with btrfs that
> occurs since 4.2.6-hardened-r6 till 4.4.2.
>
> An similar bug has been patched already
> https://patchwork.kernel.org/patch/7582351/

it doesn't look like it's the same bug (we've carried that fix for some time
now anyway), so let's investigate it first. can you print out the values of
extent_start and btrfs_file_extent_offset(leaf, fi) before line 913?