PAX size overflow false positive in 3.2.53-201312011108?
Posted: Sun Dec 01, 2013 9:14 pm
Hi,
While booting a server with grsecurity-3.0-3.2.53-201312011108.patch I got
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
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