| Summary: | hardened-sources-4.2.6-r6 PAX: size overflow detected in function try_merge_map fs/btrfs/ex tent_map.c:238 cicus.109_1 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Martin Filo <gentoo_bugs> |
| Component: | Hardened | Assignee: | The Gentoo Linux Hardened Team <hardened> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexander, atoth, gentoo, gentoo_bugs, lucy, pageexec, re.emese, spender |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Martin Filo
2015-11-28 22:00:42 UTC
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. |
