Re: [gentoo-hardened] btrfs size overflow bug since 4.2.6-hardened-r6

[Tóth Attila]

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, [phone]

2016.Március 3.(Cs) 17:44 időpontban ingo.schmitt@×××××××××××××.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 ]------------
>
>