Some programs (emerge, firefox) crashing due this bug [23202.809758] PAX: size overflow detected in function try_merge_map fs/btrfs/extent_map.c:238 cicus.109_1 02 max, count: 13, decl: block_len; num: 0; context: extent_map; [23202.809769] CPU: 3 PID: 5115 Comm: ebuild.sh Not tainted 4.2.6-hardened-r6 #1 [23202.809774] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.8.2-20150714_191116- 04/01/2014 [23202.809779] ffffffff81a04843 8afaa45f33f70ec4 0000000000000000 0000000000000000 [23202.809787] ffffc9000adb35c8 ffffffff816325b5 000000000000009b ffffffff818475a7 [23202.809794] ffffc9000adb35f8 ffffffff81153a26 ffff8801eb9fbc80 ffff880232f05380 [23202.809802] Call Trace: [23202.809815] [<ffffffff816325b5>] dump_stack+0x45/0x5d [23202.809823] [<ffffffff81153a26>] report_size_overflow+0x36/0x40 [23202.809831] [<ffffffff81293572>] try_merge_map+0x202/0x320 [23202.809837] [<ffffffff812938ed>] add_extent_mapping+0x12d/0x1b0 [23202.809845] [<ffffffff8127a61c>] btrfs_get_extent+0x67c/0xdb0 [23202.809854] [<ffffffff8129e736>] __do_readpage+0x746/0xcc0 [23202.809861] [<ffffffff8129a793>] ? __set_extent_bit+0x153/0x5e0 [23202.809869] [<ffffffff81279fa0>] ? btrfs_real_readdir+0x730/0x730 [23202.809878] [<ffffffff8129ee81>] __extent_read_full_page+0x1d1/0x200 [23202.809885] [<ffffffff81279fa0>] ? btrfs_real_readdir+0x730/0x730 [23202.809891] [<ffffffff81276fd0>] ? inode_tree_add+0x150/0x150 [23202.809898] [<ffffffff812a0719>] extent_read_full_page+0x59/0x90 [23202.809905] [<ffffffff81279fa0>] ? btrfs_real_readdir+0x730/0x730 [23202.809911] [<ffffffff81277000>] btrfs_readpage+0x30/0x40 [23202.809939] [<ffffffff81276fd0>] ? inode_tree_add+0x150/0x150 [23202.809946] [<ffffffff810f5ac4>] do_read_cache_page+0x94/0x1b0 [23202.809953] [<ffffffff81276fd0>] ? inode_tree_add+0x150/0x150 [23202.809959] [<ffffffff810f5c1b>] read_cache_page+0x3b/0x50 [23202.809965] [<ffffffff81276fd0>] ? inode_tree_add+0x150/0x150 [23202.809972] [<ffffffff8115a129>] page_getlink.isra.43.constprop.46+0x39/0xb0 [23202.809979] [<ffffffff8115a1da>] page_follow_link_light+0x3a/0x70 [23202.809985] [<ffffffff8115a957>] trailing_symlink+0x2a7/0x300 [23202.809992] [<ffffffff8115ca25>] path_lookupat+0x75/0x140 [23202.809998] [<ffffffff8115f74d>] filename_lookup+0xbd/0x1a0 [23202.810081] [<ffffffff8115f958>] user_path_at_empty+0x48/0x60 [23202.810088] [<ffffffff81151ce8>] vfs_fstatat+0x68/0xd0 [23202.810096] [<ffffffff81152148>] SYSC_newstat+0x38/0x70 [23202.810103] [<ffffffff8115272d>] SyS_newstat+0x1d/0x30 [23202.810109] [<ffffffff816380bf>] entry_SYSCALL_64_fastpath+0x16/0x89
FTR, it's been reported already: https://bugs.archlinux.org/task/47173 . you can try the logging patch as well but i'm fairly sure it's the same issue.
It's probably same bug as is reported in arch. normal output looks like: Nov 29 09:15:31 kernel: PAX: em->block_len:80000 merge->block_len:80000 Nov 29 09:15:31 kernel: PAX: em->block_len:80000 merge->block_len:100000 Nov 29 09:15:31 kernel: PAX: em->block_len:80000 merge->block_len:80000 Nov 29 09:15:31 kernel: PAX: em->block_len:80000 merge->block_len:100000 Nov 29 09:15:31 kernel: PAX: em->block_len:43000 merge->block_len:80000 Nov 29 09:15:31 kernel: PAX: em->block_len:80000 merge->block_len:80000 But when it's crash output is: Nov 29 12:05:54 kernel: PAX: em->block_len:ffffffffffffffff merge->block_len:ff ffffffffffffff Nov 29 12:05:54 kernel: PAX: size overflow detected in function try_merge_map fs /btrfs/extent_m ap.c:239 cicus.109_105 max, count: 13, decl: block_len; num: 0; context: extent_ map; Nov 29 12:05:54 kernel: CPU: 3 PID: 20551 Comm: ld Not tainted 4.2.6-hardened-r6 #2 It's bug in btrfs detected by pax, or it's bug in pax?
the values come from btrfs, the overflow plugin only detects their use that triggers an integer overflow. whether that is intended or not is something only btrfs devs can tell for sure. my guess is that (u64)-1 is used as some marker value, not an actual size value, so its use in this function is probably a sign of some higher level logic bug.
here's a discussion thread on the btrfs list: http://marc.info/?t=144862133900003&r=1&w=2 , perhaps you can try the proposed patch too (though i'm not sure if it's the right fix as it merely avoids triggering the overflow but otherwise doesn't touch the merge logic).
Patch from btrfs mailing list prevent from crash. But there is still lot of em->block_len:ffffffffffffffff merge->block_len:ffffffffffffffff. I suppose that, they know about this bug and another report is not needed.
note that the initial patch has been updated since: https://projects.archlinux.org/svntogit/community.git/tree/trunk/btrfs-overflow.patch?h=packages/linux-grsec
Thanks, I tested this one. I also updated https://bugzilla.kernel.org/show_bug.cgi?id=108531
*** Bug 567710 has been marked as a duplicate of this bug. ***
I also hit this bug. No official patch made its way into the kernel yet.
Workaround is in version 4.3.3-r2.
(In reply to Martin Filo from comment #10) > Workaround is in version 4.3.3-r2. what do you mean workaround? is it fixed in 4.3.3-r2? also i just added 4.3.3-r3 to the tree, can you test it?
(In reply to Anthony Basile from comment #11) > (In reply to Martin Filo from comment #10) > > Workaround is in version 4.3.3-r2. > > what do you mean workaround? is it fixed in 4.3.3-r2? also i just added > 4.3.3-r3 to the tree, can you test it? This is the patch 4.3.3-r2 includes: 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; Unfortunately I cannot boot 4.3.3-r2, due to an early kernel PANIC. I don't know what that is again, I will have time to submit a bug report later...
I don't understand btrfs internals maybe I'm wrong. Current patch doesn't prevent em->block_len and merge->block_len to take value 0xffffffffffffffff It only prevents overflow. I don't know if these values are wrong. There is open upstream bug https://bugzilla.kernel.org/show_bug.cgi?id=108531 regarding this.
(In reply to Anthony Basile from comment #11) > i just added 4.3.3-r3 to the tree, can you test it? I'm now running 4.3.3-r4 for some hours and this issue seems to have gone.
(In reply to Markus Oehme from comment #14) > (In reply to Anthony Basile from comment #11) > > i just added 4.3.3-r3 to the tree, can you test it? > > I'm now running 4.3.3-r4 for some hours and this issue seems to have gone. This should be fixed in all current versions in the tree.
