grsecurity forums

Hey guys,

i've discovered another size overflow, maybe false positive. this time in btrfs.
I do only have a screenshot because my system was unusable after this error.

Kernel: 3.12.2
Patch: grsecurity-3.0-3.12.2-201312021733.patch (from today, 3. Dec 2013)

See Screenshot http://www.rootfabrik.com/c03a3cec5f47910ef4bc4204d8a8c443/20131203_182543.jpg


Kind Regards, Jens

Hi,
I think it isn't a false positive but I will need more info. Could you please apply this patch:

Code: Select all

--- fs/btrfs/tree-log.c.orig    2013-12-04 15:51:09.651617174 +0100
+++ fs/btrfs/tree-log.c 2013-12-04 15:56:31.035610003 +0100
@@ -3508,6 +3508,7 @@
        csum_offset = mod_start - em->start;
        csum_len = mod_len;
 
+       printk(KERN_ERR "PAX block_start: %lx, csum_offset: %lx, csum_len: %lx\n", em->block_start, csum_offset, csum_len);
        /* block start is already adjusted for the file extent offset. */
        ret = btrfs_lookup_csums_range(log->fs_info->csum_root,
                                       em->block_start + csum_offset,


It can generate too much log so you should turn off your syslogd before rebooting into the new kernel.
Also run make fs/btrfs/tree-log.o EXTRA_CFLAGS=-fdump-tree-all and send me all the fs/btrfs/tree-log.c.* fs/btrfs/tree-log.o files.

Please make sure the screenshot includes the full message because it contains important information.

Hey,

the requested tree-log files are here (triggered with the above make args): http://www.rootfabrik.com/c03a3cec5f479 ... log.tar.gz
The screenshot/logs with the new requested debugging-code will come soon.

many thanks, Jens

hey there,

this is the missing screenshot of the error: http://www.rootfabrik.com/c03a3cec5f47910ef4bc4204d8a8c443/20131205_193338.jpg



regards, jens

ok, this is something you'll have to work out with upstream because it looks like some logic error. what happened was that fs/btrfs/tree-log.c:log_one_extent was called with an extent_map whose block_start field had a special value (EXTENT_MAP_HOLE/ffff_ffff_ffff_fffd) instead of some real block number yet btrfs_lookup_csums_range ended up getting called with this value and the overflow plugin triggered on the resulting overflow when block_start+csum_offset+csum_len was calculated. now i know nothing about btrfs internals but my gut feeling is that btrfs_lookup_csums_range expects valid ranges, not something computed from the magic values of EXTENT_MAP_*.

hey guys,

i've created a bug-report on kernel.org and recv a reply.
maybe someone can check this?

https://bugzilla.kernel.org/show_bug.cgi?id=66661

thanks for the quick turnaround, as you can see you and the size overflow plugin ran into a real bug. i'll backport the fix myself into the next PaX patch (and since it's so simple you can apply it yourself in the meantime, perhaps you'll then trigger more bugs ).