PAX size overflow false positive in 3.2.53-201312011108?

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

PAX size overflow false positive in 3.2.53-201312011108?

Postby jorgus » Sun Dec 01, 2013 9:14 pm

Hi,

While booting a server with grsecurity-3.0-3.2.53-201312011108.patch I got

Code: Select all
PAX: size overflow detected in function xlog_grant_push_ail fs/xfs/xfs_log_priv.h:585 cicus.288_95 max, count: 25
grsec: time set by /usr/sbin/ntpdate[ntpdate:3792] uid/euid:0/0 gid/egid:0/0, parent /etc/network/if-up.d/ntpdate[ntpdate:1738] uid/euid:0/0 gid/egid:0/0
PAX: size overflow detected in function xlog_grant_push_ail fs/xfs/xfs_log_priv.h:585 cicus.288_95 max, count: 25
PAX: size overflow detected in function xlog_grant_push_ail fs/xfs/xfs_log_priv.h:585 cicus.288_95 max, count: 25
PAX: size overflow detected in function xlog_grant_push_ail fs/xfs/xfs_log_priv.h:585 cicus.288_95 max, count: 25
BUG: unable to handle kernel paging request at fffffffffffffff8
IP: [<ffffffff8106fb3c>] kthread_data+0xc/0x20
PGD 13e2067 PUD 13e4067 PMD 0
Oops: 0000 [#1] SMP
CPU 0
Modules linked in: binfmt_misc xen_wdt ipt_LOG xt_owner ipt_REJECT xt_tcpudp xt_multiport xt_state iptable_mangle iptable_raw iptable_nat nf_nat iptable_filter ip_tables x_tables nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack joydev usbhid floppy processor thermal_sys uhci_hcd ehci_hcd xen_netfront i2c_piix4 i2c_core button evdev psmouse usbcore usb_common unix

Pid: 10, comm: kworker/0:1 Not tainted 3.2.53-1-domu #1 Xen HVM domU
RIP: 0010:[<ffffffff8106fb3c>]  [<ffffffff8106fb3c>] kthread_data+0xc/0x20
RSP: 0018:ffff8802070f9ab8  EFLAGS: 00010086
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88020fc00000
RDX: 0000000000000008 RSI: 0000000000000000 RDI: ffff8802070f4e80
RBP: ffff8802070f9ad0 R08: ffffffffffc6e21c R09: 000000085774544b
R10: 000000085774544b R11: 0000000000009024 R12: ffff8802070f5118
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88020fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: fffffffffffffff8 CR3: 00000000013c6000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kworker/0:1 (pid: 10, threadinfo ffff8802070f5270, task ffff8802070f4e80)
Stack:
 ffffffff8106aab0 ffff8802070f9ad0 ffff88020fc0e780 ffff8802070f9c00
 ffffffff813b4037 ffff8802028db000 ffff8802028db000 ffff8801f3e155e0
 ffff8802070f5270 ffffffff8103f840 ffff8802070f5270 ffff8801f6287330
Call Trace:
 [<ffffffff8106aab0>] ? wq_worker_sleeping+0x10/0xb0
 [<ffffffff813b4037>] __schedule+0x507/0x9e0
 [<ffffffff8103f840>] ? hrtick_start_fair+0x190/0x190
 [<ffffffff81099c20>] ? call_rcu_sched+0x10/0x20
 [<ffffffff812104a4>] ? cfq_cic_free+0x14/0x20
 [<ffffffff8121106a>] ? cic_free_func+0x7a/0xa0
 [<ffffffff81210ff0>] ? cfq_prio_tree_add+0xd0/0xd0
 [<ffffffff81205ee6>] ? put_io_context+0x56/0x80
 [<ffffffff813b45da>] schedule+0x3a/0x60
 [<ffffffff81051fff>] do_exit+0x72f/0x9e0
 [<ffffffff8100e607>] ? show_trace_log_lvl+0x57/0x80
 [<ffffffff8105232a>] do_group_exit+0x3a/0xb0
 [<ffffffff8110179e>] report_size_overflow+0x2e/0x30
 [<ffffffff811d01f9>] xlog_grant_push_ail+0xd9/0x250
 [<ffffffff811d2b15>] xfs_log_reserve+0xf5/0x150
 [<ffffffff811cda37>] xfs_trans_reserve+0x97/0x210
 [<ffffffff81183c2e>] xfs_fs_log_dummy+0x3e/0x90
 [<ffffffff8118f984>] xfs_sync_worker+0x84/0x90
 [<ffffffff81068c31>] process_one_work+0x141/0x390
 [<ffffffff8123b5a2>] ? __list_add+0x22/0x50
 [<ffffffff810693ee>] worker_thread+0x12e/0x300
 [<ffffffff810692c0>] ? manage_workers.isra.32+0x200/0x200
 [<ffffffff8106f903>] kthread+0x93/0xa0
 [<ffffffff813b93e9>] kernel_thread_helper+0x9/0x20
 [<ffffffff813b681a>] ? retint_restore_args+0xb/0x12
 [<ffffffff8106f870>] ? kthread_worker_fn+0x1a0/0x1a0
 [<ffffffff813b93e0>] ? gs_change+0x13/0x13
Code: c9 00 00 00 48 c7 c7 46 23 4f 81 e8 5f e1 fd ff eb da 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 8b 87 40 02 00 00 55 48 89 e5 5d <48> 8b 40 f8 48 0f ba 2c 24 3f c3 66 0f 1f 84 00 00 00 00 00 48
RIP  [<ffffffff8106fb3c>] kthread_data+0xc/0x20
 RSP <ffff8802070f9ab8>
CR2: fffffffffffffff8
---[ end trace a80093adbbec6be6 ]---
Kernel panic - not syncing: Fatal exception


It booted successfully the next time, though it seems that it may be unstable. As it turned out a few hours later, that panic resulted in a serious filesystem corruption, which came unnoticed at first.

Best regards,
Szymon
jorgus
 
Posts: 65
Joined: Wed Feb 20, 2008 9:50 pm

Re: PAX size overflow false positive in 3.2.53-201312011108?

Postby ephox » Mon Dec 02, 2013 2:32 pm

Hi,

Could you run make fs/xfs/xfs_log.o EXTRA_CFLAGS=-fdump-tree-all and send me all the fs/xfs/xfs_log.c.* fs/xfs/xfs_log.o files?
Which gcc version did you use?
Thanks, Emese
ephox
 
Posts: 134
Joined: Tue Mar 20, 2012 4:36 pm

Re: PAX size overflow false positive in 3.2.53-201312011108?

Postby jorgus » Mon Dec 02, 2013 3:03 pm

ephox wrote:Hi,

Could you run make fs/xfs/xfs_log.o EXTRA_CFLAGS=-fdump-tree-all and send me all the fs/xfs/xfs_log.c.* fs/xfs/xfs_log.o files?
Which gcc version did you use?
Thanks, Emese


Hi,

I've sent you a link to the files via a PM.
jorgus
 
Posts: 65
Joined: Wed Feb 20, 2008 9:50 pm

Re: PAX size overflow false positive in 3.2.53-201312011108?

Postby ephox » Mon Dec 02, 2013 4:38 pm

This bug is a false positive. There will be a temporary fix in the next PaX version, later I will release the final fix.
ephox
 
Posts: 134
Joined: Tue Mar 20, 2012 4:36 pm

Re: PAX size overflow false positive in 3.2.53-201312011108?

Postby jorgus » Wed Dec 04, 2013 7:13 pm

Thank you very much. So far no more fs corruption, although it was not that clear-cut and happened only on one system out of a few.

Szymon
jorgus
 
Posts: 65
Joined: Wed Feb 20, 2008 9:50 pm


Return to grsecurity support

cron