PAX_RAP at work

[miroR]

This is manually copied screen with possible typoes (but likely not many nor grave), the panic happened very soon after boot.

[   32.097759] CPU: 0 PID: 7 Comm: rcu_sched Tainted: G     D           4.9.73-unofficial+grsec171230-04 #1 
[   32.102705] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./970 Extreme4, BIOS P2.60 11/11/2013
[   32.107654]  ffffc90000003d98 ffffffff818038c6 0000000000000000 0000000000000000 
[   32.112652]  ffffc90000003dd8 ffffffff81118205 0000007f8116c2ad 0000000000000001 
[   32.117637]  ffff88032fc946c0 0000000000000000 ffff8803216b2c40 ffff88032fc10dc0 
[   32.122570] Call Trace: 
[   32.127391]  <IRQ> [   32.127441]  [<ffffffff818038c6>] dump_stack+0x81/0xcb 
[   32.132297]  [<ffffffff81118205>] __warn+0x185/0x1c0
[   32.137146]  [<ffffffff81118439>] warn_slowpath_null +0x49/0x80 
[   32.141921]  [<ffffffff810b8245>] native_smp_send_reschedule+0x95/0xb0 
[   32.146662]  [<ffffffff8117bda5>] trigger_load_balance+0x1d5/0x2a0 
[   32.151291]  [<ffffffff81161456>] scheduler_tick+0x136/0x1a0 
[   32.155864]  [<ffffffff811b3b46>] update_process_times+0x96/0xe0
[   32.160346]  [<ffffffff811ce71a>] tick_sched_handle.isra.16+0x6a/0xa0 
[   32.164833]  [<ffffffff811cf00c>] tick_sched_timer+0x7c/0xe0
[   32.169266]  [<ffffffff811b4776>] __hrtimer_run_queues+0x106/0x220 
[   32.173717]  [<ffffffff811b56dd>] hrtimer_interrupt+0xcd/0x210
[   32.178138]  [<ffffffff810bbd7c>] local_apic_timer_interrupt+0x9d/0xf0 
[   32.182599]  [<ffffffff810bd38d>] smp_apic_timer_interrupt+0x9d/0xf0 
[   32.186998]  [<ffffffff82569d02>] apic_timer_interrupt+0xb2/0xc0 
[   32.191358]  <EOI> [   32.191408]  [<ffffffff8122cfea>] ? panic+0x2f8/0x379 
[   32.195790]  [<ffffffff8122cfed>] ? panic+0x2fb/0x379
[   32.200134]  [<ffffffff8108e914>] ? oops_end+0x84/0x100 
[   32.204421]  [<ffffffff817ed7ad>] gr_handle_kernel_exploit+0x1bd/0x1d0 
[   32.208748]  [<ffffffff8108e943>] oops_end+0xb3/0x100 
[   32.213041]  [<ffffffff8108eb8c>] die+0x8c/0xf0 
[   32.217258]  [<ffffffff81089e99>] do_trap+0xb9/0x280 
[   32.221449]  [<ffffffff8108a134>] do_error_trap+0xd4/0x180
[   32.225654]  [<ffffffff811a8890>] ? sync_exp_work_done.part.16+0x50/0x50 
[   32.229897]  [<ffffffff8108abfe>] do_rap_ret_error+0x4e/0x80 
[   32.234139]  [<ffffffff8256a982>] rap_ret_error+0x32/0x40
[   32.238409]  [<ffffffff811a8890>] ? sync_exp_work_done.part.16+0x50/0x50 
[   32.242685]  [<ffffffff811ab948>] ? force_qs_rnp+0x128/0x240 
[   32.246798]  [<ffffffff811a8902>] ? dyntick_save_progress_counter+0x72/0x90 
[   32.250787]  [<ffffffff811ab948>] force_qs_rnp+0x128/0x240  
[   32.254714]  [<ffffffff811abe28>] rcu_qp_kthread+0x3c8/0xa80 
[   32.258593]  [<ffffffff811aba60>] ? force_qs_rnp+0x240/0x240 
[   32.262458]  [<ffffffff81150681>] kthread+0x161/0x1a0 
[   32.266222]  [<ffffffff81150520>] ? __kthread_parkme+0xd0/0xd0 
[   32.269919]  [<ffffffff82569288>] ret_from_fork+0x88/0xa0 
[   32.273504]  --[ end trace 40f9b8955beb4e3b ]--- 

After tolied a little to copy that, I rebooted. On the next (mechanical) reboot:

early console in extact_kernel
input_data: 0x0000000002d8343b4
input_len: 0x0000000000059274
output: 0x0000000001000000
output_len: 0x00000000024ba868
kernel_total_size: 0x0000000003600000

Decompressing Linux...

XZ-compressed data is corrupt

 -- System halted

And one more time on the next (mechanical) reboot:

Upon issuing

$ startx

some terminals opened (almost all) and Xorg froze (with likely kernel crash having happened).

But nothing in the logs.

And afterwards, the system again appears to work just fine.

Someone more knowledgeable (minipli of HacKurx or someone else) pls. change the title to a better fit.

[miroR]

I think I should add that I had previously tested the newly compiled:

# uname -r
4.9.73-unofficial+grsec171229-21
#

which has no CONFIG_PAX_RAP set. That's the all-modules-any-system kernel that I would have uploaded last night at: https://www.croatiafidelis.hr/gnu/deb/ but I'm not sure how serious the missing functionality is... (BTW most grsec general purpose kernels go without it, to my uncertain knowledge about it)

This one is my-system-hardware-only no-modules-loading-at-all kernel, where this happened, after the system was exposed to online with the no-PAX_RAP kernel above... [This one is] the PAX_RAP kernel of this issue:

# uname -r
4.9.73-unofficial+grsec171230-04
# 

(but the system must have picked up something from online in the previous kernel, or there's some thing(s) in the system from the long exposure to attacks in the past weeks).

[miroR]

An issue that appeared in my recently compiled dappersec kernel 4.9.105 at https://github.com/dapperlinux/dapper-secure-kernel-patchset-stable/issues/6#issue-330891072 I was able to present more quickly by searching through some of the archived call traces (all or almost all in only one particular clone of all my systems, all based on same Devuan OS), by copying it, and manually changing the differences, which is this Call Trace below.

[....] Waiting for /dev to be fully populated...[   39.701764] PAX: RAP hash violation for return address: force_qs_rnp+0x128/0x240
[   39.702912] PAX: overwritten return address detected: 0000 [#1] SMP
[   39.704072] CPu: 0 PID: 7 Comm: rcu_sched Not tainted 4.9.73-unofficial+grsec171230-04 #1
[   39.705242] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./970 Extreme4, BIOS P2.60 11/11/2013
[   39.706456] task: ffff8803216b2c40 task.stack: ffffc900018f0000
[   39.707677] RIP: 0010:[<ffffffff811a8902>]  [<ffffffff811a8902>] dyntick_save_progress_counter+0x72/0x90
[   39.708941] RSP: 0018:ffffc900018f3dd0  EFLAGS: 00000087
[   39.710205] RAX: 0000000000000001 RBX: ffff88032fc953c0 RCX: ffffffff811ab948
[   39.711493] RDX: 400000000000065c RSO: ffffc900018f3e5f RDI: ffff88032fc953c0
[   39.712792] RBP: ffffc900018f3dd8 R08: ffff88032fc0e8c0 R09: 0000000000000000
[   39.714085] R10: 0000000000000000 R11: ffff88031d862e00 R12: 0000000000000000
[   39.715365] R13: ffffffff82e39400 R14: ffffffff811a8890 R15: 0000000000000001
[   39.716635] FS:  0000000000000000(0000) GS: ffff88032fc00000(0000) knlGS:0000000000000000
[   39.717911] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   39.719172] CR2: 0000000a7eaf9018 CR3: 0000000002c1e000 CR4: 00000000000006f0
[   39.720437] Stack:
[   39.721656]  ffffffff82e39400 ffffc900018f3d30 ffffffff811ab948 0000000000000282
[   39.722895]  ffffc900018f3e60 ffffc900018f3e5f 0000000000000002 ffffffff82e39660
[   39.724130]  0000000000000001 0000000000000000 0000000000000000 ffffffff82e39400
[   39.725368] Call Trace:
[   39.727786]  [<ffffffff811ab948>] force_qs_rnp+0x128/0x240
[   39.727786]  [<ffffffff811abe28>] rcu_qp_kthread+0x3c8/0xa80
[   39.728963]  [<ffffffff811aba60>] ? force_qs_rnp+0x240/0x240
[   39.730168]  [<ffffffff81150681>] kthread+0x161/0x1a0
[   39.731365]  [<ffffffff81150520>] ? __kthread_parkme+0xd0/0xd0
[   39.732564]  [<ffffffff82569288>] ret_from_fork+0x88/0xa0
[   39.733759] Code: 48 01 c2 48 3b 51 08 b8 01 00 00 00 78 17 48 8b 4d 08 48 81 79 f0 1a 02 ed 84 75 0f 5b 5d 48 0f ba 2c 24 3f c3 c6 43 1c 01 eb e3 <cd> 83 66  90 66 2e 0f 1f 84 00 00 00 00 00 cc cc cc cc cc 48
[   39.736392] RIP  [<ffffffff811a8902>] dyntick_save_progress_counter+0x72/0x90
[   39.737675]  RSP <ffffc900018f3dd0>
[   39.738950] ---[ end trace 014216cb4717cd62 ]---
[   39.740231] Kernel panic - not syncing: grsec: halting the system due to suspicious kernel crash caused by root
[   40.828547] Shutting down cups with NMI
[   40.829791] Kernel Offset: disabled
[   40.830983] ---[ end Kernel panic - not syncing: grsec: halting the system due to suspicious kernel crash caused by root

I'm still at the onset of my tries to really understand C. But should in here not be some indications to the code related to which/based on some tricks played on which/something else done related to that code somehow this bug happens?

If only spender and PaX Team would care to look into this and give advice...