kernel: PAX: size overflow detected in function invalidate_inode_pages2_range mm/truncate.c:605 cicus.113_193 max, count: 5, decl: unmap_mapping_range; num: 3; context: fndecl; kernel: CPU: 2 PID: 1807 Comm: xfs_fsr Not tainted 4.4.8-hardened-r1 #5 kernel: Hardware name: System manufacturer System Product Name/P8B WS, BIOS 2106 07/16/2012 kernel: 60cfec9bb13d66cf 60cfec9bb13d66cf 0000000000000000 ffffffffa2429f7b kernel: ffffffffa8a0b966 60cfec9bb13d66cf ffffffffa8a0b958 ffff8807fe9ae4d0 kernel: ffffffffa21e4030 ffffea001fe42080 ffffc90007f73cf0 ffff8807fe9ae548 kernel: Call Trace: kernel: [<ffffffffa2429f7b>] ? dump_stack+0x71/0xb4 kernel: [<ffffffffa21e4030>] ? report_size_overflow+0x36/0x6f kernel: [<ffffffffa2184d49>] ? invalidate_inode_pages2_range+0x276/0x4d2 kernel: [<ffffffffa2176904>] ? find_get_pages_tag+0xfb/0x14d kernel: [<ffffffffa234b17f>] ? xfs_file_read_iter+0x189/0x233 kernel: [<ffffffffa234b17f>] ? xfs_file_read_iter+0x189/0x233 kernel: [<ffffffffa21dcb81>] ? __vfs_read+0xe2/0x120 kernel: [<ffffffffa21dd664>] ? vfs_read+0x148/0x1ee kernel: [<ffffffffa21de593>] ? SyS_read+0x62/0xb7 kernel: [<ffffffffa280fbb0>] ? entry_SYSCALL_64_fastpath+0x12/0x8a kernel: [<ffffffffa280fbe7>] ? entry_SYSCALL_64_fastpath+0x49/0x8a kernel: [<ffffffffa280fbe7>] ? entry_SYSCALL_64_fastpath+0x49/0x8a
This is pretty sketchy details. See [1]. I'll pass it on to upstream but they may ask for more details. [1] https://en.wikibooks.org/wiki/Grsecurity/Reporting_Bugs
Hi, I think it can be a real bug. Could you please apply this patch: --- mm/truncate.c.orig 2016-05-27 18:30:02.077863185 +0200 +++ mm/truncate.c 2016-05-27 18:32:14.361864968 +0200 @@ -602,6 +602,7 @@ /* * Zap the rest of the file in one hit. */ + printk(KERN_ERR "PAX: end: %lx index: %lx\n", end, index); unmap_mapping_range(mapping, (loff_t)index << PAGE_CACHE_SHIFT, (loff_t)(1 + end - index) and send me the results from dmesg? Please also enable the CONFIG_FRAME_POINTER kernel config option.
Hit the same or similar bug on "invalidate_inode_pages2_range mm/truncate.c". Should I follow this bug or file a new one? 12:04:50 kernel: [911270.488067] PAX: size overflow detected in function invalidate_inode_pages2_range mm/truncate.c:605 cicus.121_185 max, count: 5, decl: unmap_mapping_range; num: 3; context: fndecl; 12:04:50 kernel: [911270.488130] CPU: 9 PID: 38988 Comm: php-cgi Not tainted 4.4.5-hardened-r2 #1 12:04:50 kernel: [911270.488134] Hardware name: Dell Inc. PowerEdge M520/0JNYNG, BIOS 2.4.2 02/03/2015 12:04:50 kernel: [911270.488137] ffffffff81e05887 0000000000000286 0000000000000000 ffffc9001840ba10 12:04:50 kernel: [911270.488144] ffffffff812fd531 0000000000000001 ffffffff81b26c1d 000000000000025d 12:04:50 kernel: [911270.488148] ffffc9001840ba40 ffffffff8115c52c 0000000000000006 0000000000000006 12:04:50 kernel: [911270.488153] Call Trace: 12:04:50 kernel: [911270.488172] [<ffffffff812fd531>] dump_stack+0x4e/0x7d 12:04:50 kernel: [911270.488181] [<ffffffff8115c52c>] report_size_overflow+0x6c/0x80 12:04:50 kernel: [911270.488190] [<ffffffff81108d9a>] invalidate_inode_pages2_range+0x29a/0x5d0 12:04:50 kernel: [911270.488195] [<ffffffff811090e9>] invalidate_inode_pages2+0x19/0x20 12:04:50 kernel: [911270.488204] [<ffffffff8126d0a8>] nfs_invalidate_mapping+0x88/0xc0 12:04:50 kernel: [911270.488209] [<ffffffff812ee3e9>] ? gr_learn_resource+0x39/0x260 12:04:50 kernel: [911270.488214] [<ffffffff8126d5c3>] __nfs_revalidate_mapping+0x1e3/0x200 12:04:50 kernel: [911270.488220] [<ffffffff8126d93a>] nfs_revalidate_mapping+0x1a/0x30 12:04:50 kernel: [911270.488225] [<ffffffff81269ba9>] nfs_file_mmap+0x39/0x50 12:04:50 kernel: [911270.488232] [<ffffffff8112cf53>] mmap_region+0x533/0x880 12:04:50 kernel: [911270.488237] [<ffffffff8112912c>] ? get_unmapped_area+0x12c/0x150 12:04:50 kernel: [911270.488241] [<ffffffff8112d827>] do_mmap+0x587/0x630 12:04:50 kernel: [911270.488246] [<ffffffff81114a3d>] vm_mmap_pgoff+0x6d/0xb0 12:04:50 kernel: [911270.488250] [<ffffffff8112aa88>] SyS_mmap_pgoff+0x188/0x230 12:04:50 kernel: [911270.488258] [<ffffffff81009720>] SyS_mmap+0x50/0x70 12:04:50 kernel: [911270.488268] [<ffffffff8188e9f8>] entry_SYSCALL_64_fastpath+0x12/0x88
> Hit the same or similar bug on "invalidate_inode_pages2_range > mm/truncate.c". Should I follow this bug or file a new one? > Are you using hardened-sources-4.4.8-r1 ?
if you can reproduce it you should apply Emese's debug patch and post the results, unfortunately without it we can't tell if it's a real problem or a false positive.
Created attachment 448206 [details] dmesg
Sorry for my latency, all. I'm now on sys-kernel/hardened-sources-4.7.4-r1 and this is still showing up. below is the stack trace with the patch applied. ... * Applying user patches from /etc/portage/patches/sys-kernel/hardened-sources ... * Done with patching ... cat /etc/portage/patches/sys-kernel/hardened-sources/truncate.c --- mm/truncate.c.orig 2016-05-27 18:30:02.077863185 +0200 +++ mm/truncate.c 2016-05-27 18:32:14.361864968 +0200 @@ -602,6 +602,7 @@ /* * Zap the rest of the file in one hit. */ + printk(KERN_ERR "PAX: end: %lx index: %lx\n", end, index); unmap_mapping_range(mapping, (loff_t)index << PAGE_CACHE_SHIFT, (loff_t)(1 + end - index) ... Sep 28 14:07:50 localhost kernel: PAX: size overflow detected in function invalidate_inode_pages2_range mm/truncate.c:608 cicus.128_227 max, count: 5, decl: unmap_mapping_range; num: 3; context: fndecl; Sep 28 14:07:50 localhost kernel: CPU: 2 PID: 1865 Comm: xfs_fsr Not tainted 4.7.4-hardened-r1 #4 Sep 28 14:07:50 localhost kernel: Hardware name: System manufacturer System Product Name/P8B WS, BIOS 2106 07/16/2012 Sep 28 14:07:50 localhost kernel: ffffffff8f13cab6 4ac66b9efbce80b8 0000000000000000 ffffc90007eb3bc0 Sep 28 14:07:50 localhost kernel: ffffffff8f4ee875 0000000000000260 4ac66b9efbce80b8 ffffffff8fe0445a Sep 28 14:07:50 localhost kernel: ffffffff8fe04468 ffffc90007eb3bf0 ffffffff8f225ffb ffffea00207d1f40 Sep 28 14:07:50 localhost kernel: Call Trace: Sep 28 14:07:50 localhost kernel: [<ffffffff8f13cab6>] ? dump_stack_print_info+0x98/0xaf Sep 28 14:07:50 localhost kernel: [<ffffffff8f4ee875>] dump_stack+0x74/0xbb Sep 28 14:07:50 localhost kernel: [<ffffffff8f225ffb>] report_size_overflow+0x3f/0x82 Sep 28 14:07:50 localhost kernel: [<ffffffff8f1b5973>] invalidate_inode_pages2_range+0x29a/0x545 Sep 28 14:07:50 localhost kernel: [<ffffffff8f1b5c36>] invalidate_inode_pages2+0x18/0x28 Sep 28 14:07:50 localhost kernel: [<ffffffff8f1a5e4c>] ? filemap_write_and_wait+0x29/0x4c Sep 28 14:07:50 localhost kernel: [<ffffffff8f1b5c36>] ? invalidate_inode_pages2+0x18/0x28 Sep 28 14:07:50 localhost kernel: [<ffffffff8f3ef5dd>] xfs_file_read_iter+0x17e/0x22f Sep 28 14:07:50 localhost kernel: [<ffffffff8f21cddb>] __vfs_read+0x12b/0x173 Sep 28 14:07:50 localhost kernel: [<ffffffff8f21decd>] vfs_read+0x14d/0x273 Sep 28 14:07:50 localhost kernel: [<ffffffff8f21f898>] sys_read+0x61/0xc0 Sep 28 14:07:50 localhost kernel: [<ffffffff8f21f898>] ? sys_read+0x61/0xc0 Sep 28 14:07:50 localhost kernel: [<ffffffff8fa49b50>] entry_SYSCALL_64_fastpath+0x1a/0xbd the command I'm running is '/usr/sbin/xfs_fsr -t 21600' I've attached dmesg, as well.
thanks but your dmesg seems to be truncated as it contains neither the added debug messages nor the size overflow report that you pasted...
Right, because it hangs the box. I pasted the overflow error earlier. Did the patch not apply on my second attempt?
This is from the last one PAX: size overflow detected in function invalidate_inode_pages2_range mm/truncate.c:608 cicus.128_227 max, count: 5, decl: unmap_mapping_range; num: 3; context: fndecl; CPU: 3 PID: 2421 Comm: xfs_fsr Not tainted 4.7.4-hardened-r1 #5 Hardware name: System manufacturer System Product Name/P8B WS, BIOS 2106 07/16/2012 ffffffffa313cabe 9a5c4f8fe2470ce7 0000000000000000 ffffc9000d023b60 ffffffffa34ee815 0000000000000260 9a5c4f8fe2470ce7 ffffffffa3e04df2 ffffffffa3e04e00 ffffc9000d023b90 ffffffffa3225f9a ffffea001fe35100 Call Trace: [<ffffffffa313cabe>] ? dump_stack_print_info+0x98/0xaf [<ffffffffa34ee815>] dump_stack+0x74/0xbb [<ffffffffa3225f9a>] report_size_overflow+0x3f/0x82 [<ffffffffa31b5912>] invalidate_inode_pages2_range+0x29a/0x545 [<ffffffffa31b5bd5>] invalidate_inode_pages2+0x18/0x28 [<ffffffffa31a5deb>] ? filemap_write_and_wait+0x29/0x4c [<ffffffffa31b5bd5>] ? invalidate_inode_pages2+0x18/0x28 [<ffffffffa33ef57d>] xfs_file_read_iter+0x17e/0x22f [<ffffffffa321cd7a>] __vfs_read+0x12b/0x173 [<ffffffffa321de6c>] vfs_read+0x14d/0x273 [<ffffffffa321f837>] sys_read+0x61/0xc0 [<ffffffffa321f837>] ? sys_read+0x61/0xc0 [<ffffffffa3a4cc10>] entry_SYSCALL_64_fastpath+0x1a/0xbd Sep 28 14:40:52 localhost syslog-ng[1329]: syslog-ng starting up; version='3.7.3'
I knew xfs_progs was slotted to the kernel, this was with v4.5 of xfsprogs, but there is a bug open on v4.7.0 [1] and it won't compile for me either. [1] https://bugs.gentoo.org/show_bug.cgi?id=590900
the thing is that you should also get a message from the patch just before the overflow is reported, that's the one that will help us decide what to do with this size overflow report. as for crashing/hanging the machine, you can always boot with pax_size_overflow_report_only.
An actual .patch file would have helped me immensely. I couldn't get it to apply, apparently. Anyhow, I'm not seeing kernel 4.7.10 hardened being effected by this any longer, with sys-fs/xfsprogs-4.5.0. there is a bug open for v4.7.0. I had not tried 4.7.9.
I spoke to soon, bug is still present with 4.7.10-hardened.
Created attachment 451312 [details, diff] print debug info for invalidate_inode_pages2_range i generated a patch for 4.7.10, you can use it along with the pax_size_overflow_report_only kernel command line option to get the full report.
Created attachment 451346 [details] output.log Thank you for the patch file. I hope this output helps.
thanks for the info, what happens here is various kinds of integer problems and you'll have to ask upstream developers about what the intended behaviour is supposed to be here. the fundamental problem is that invalidate_inode_pages2 calls invalidate_inode_pages2_range with a -1 value for the 'end' parameter, which is an unsigned long and will be converted to ULONG_MAX (the 0xffffffffffffffff value in the debug message). later invalidate_inode_pages2_range calls unmap_mapping_range with (loff_t)(1 + end - index) << PAGE_SHIFT for the 'holelen' parameter which suffers from multiple integer problems that the plugin detects. first, 1+end overflows to 0 (which is defined by C but for size related values the plugin catches such problems regardless). next, 0-index = -index which will be converted to loff_t which is a signed type (long long) so the actual left hand side value of the following left shift will be a negative value (or 0 on the first iteration) and shifting such values is undefined behaviour and the resulting integer value is probably not at all what is intended. i think invalidate_inode_pages2 should use something like (OFFSET_MAX >> PAGE_SHIFT) - 1 instead of -1 to describe the whole file range but i'd rather not make this change myself without consulting upstream developers. so please report this problem to them (linux-mm and linux-fsdevel are the best candidates) and CC Emese, spender and me on the discussion. speaking of integer problems, the definition of OFFSET_MAX is wrong too as it relies on left shifting a signed value into the sign bit (1LL << 63) which is also undefined behaviour itself, it'd probably be easiest to just use LLONG_MAX instead.
Reported upstream. @grsecurity and @freemail.hu CC's bounced, though. Sorry for the CC spam Emese.
You need to fix your mail server, many mail servers aren't going to accept mails from you. warning: hostname organizedmagnetism.com does not resolve to address x.x.x.x NOQUEUE: reject: RCPT from unknown[x.x.x.x]: 504 5.5.2 <aristotle>: Helo command rejected: need fully-qualified hostname; from=<om@organizedmagnetism.com> to=<spender@grsecurity.net> proto=ESMTP helo=<aristotle> -Brad
