It did last for days without issue. But, on the usual one particular system only (a clone of same master as other of my systems that do not show any issues; clone meaning: same software on same model MBO and similar other hardware, i.e. cloned Devuan system on all)...
(NOTE: the timing contains some approximation in this manually copied trace, meaning there might be other errors)
But, on that one system I got a similar bug as minipli/linux-unofficial_grsec#23 :
[ 56.413784] PAX: overwritten return address detected: 0000 [#1] SMP
[ 56.414964] grsec: exec of /bin/run-parts (run-parts --lsbsysinit --list /lib/lsb/init-functions.d ) by /bin/run-parts[x11-common:2143] uid/euid0/0 gid/egid:0/0, parent /etc/init.d/x11-common[x11-common:2134] uid/euid:0/0 gid/egid:0/0
[ 56.414967] grsec: exec of /usr/bin/tput (/usr/bin/tput hpa 60 ) by /usr/bin/tput [x11-common:2144] uid/euid:0/0 gid/egid:0/0, parent /etc/init.d/x11-common[x11-common:2134] uid/euid:0/0 gid/egid:0/0
[ 56.44xxxx] CPU: 1 PID: 7 Comm: rcu_sched Not tainted 4.9.105-dappersec180605-23 #1
[ 56.44xxxx] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./970 Extreme4, BIOS P2.60 11/11/2013
[ 56.44xxxx] task: ffff8803216b2c40 task.stack: ffffc900018f0000
[ 56.44xxxx] RIP: 0010:[<ffffffff811a8d82>] [<ffffffff811a8d82>] dyntick_save_progress_counter+0x72/0x90
[ 56.44xxxx] RSP: 0018:ffffc900018f3dd0 EFLAGS: 00000087
[ 56.45xxxx] RAX: 0000000000000001 RBX: ffff88032fc153c0 RCX: ffffffff82e394c0
[ 56.45xxxx] RDX: RSI: ffffc900018f3e5f RDI: ffff88032fc153c0
[ 56.45xxxx] RBP: ffffc900018f3dd8 R08: ffff88032fc8e8c0 R09: 0000000000000000
[ 56.45xxxx] R10: 0000000000000003 R11: ffff88031d862e00 R12: 0000000000000000
[ 56.45xxxx] R13: ffffffff82e394c0 R14: ffffffff811a8890 R15: 0000000000000000
[ 56.55xxxx] FS: 0000000000000000(0000) GS: ffff88032fc00000(0000) knlGS:0000000000000000
[ 56.55xxxx] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 56.55xxxx] CR2: 0000034742ade940 CR3: 0000000002c11000 CR4: 00000000000006f0
[ 56.57xxxx] Stack:
[ 56.57xxxx] ffffffff82e39400 ffffc900018f3e30 ffffffff811abdc8 0000000000000282
[ 56.57xxxx] ffffc900018f3e60 ffffc900018f3e5f 0000000000000001 ffffffff82e39720
[ 56.57xxxx] 0000000000000001 0000000000000000 0000000000000000 ffffffff82e394c0
[ 56.57xxxx] Call Trace:
[ 56.57xxxx] [<ffffffff811abdc8>] force_qs_rnp+0x128/0x240
[ 56.57xxxx] [<ffffffff811ac2a8>] rcu_qp_kthread+0x3c8/0xa80
[ 56.57xxxx] [<ffffffff811abee0>] ? force_qs_rnp+0x240/0x240
[ 56.58xxxx] [<ffffffff811508e1>] kthread+0x161/0x1a0
[ 56.58xxxx] [<ffffffff81150780>] ? __kthread_parkme+0xd0/0xd0
[ 56.58xxxx] [<ffffffff8256dbc8>] ret_from_fork+0x88/0xa0
[ 56.58xxxx] Code: 48 01 c2 48 3b 51 08 b8 01 00 00 00 78 17 48 8b 55 08 48 81 7a 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 cc 48
[ 56.436392] RIP [<ffffffff811a8d82>] dyntick_save_progress_counter+0x72/0x90
[ 56.437675] RSP <ffffc900018f3dd0>
[ 56.438950] ---[ end trace da957e686ba27a86 ]---
[ 56.440231] Kernel panic - not syncing: grsec: halting the system due to suspicious kernel crash caused by root
[ 57.xxxxxx] Shutting down cups with NMI
[ 57.xxxxxx] Kernel Offset: disabled
[ 57.xxxxxx] ---[ end Kernel panic - not syncing: grsec: halting the system due to suspicious kernel crash caused by root
Who can tell what causes this? What info do I need to provide?... (No leads in the last end of year/start of this year bugs in minipli's unofficial_grsec...)
Upon rebooting the system, all is now fine since then (uptime only 4:00 hours since then. That happened at 09:52 this morning UTC. Now is 14:00 UTC.
It did last for days without issue. But, on the usual one particular system only (a clone of same master as other of my systems that do not show any issues; clone meaning: same software on same model MBO and similar other hardware, i.e. cloned Devuan system on all)...
(NOTE: the timing contains some approximation in this manually copied trace, meaning there might be other errors)
But, on that one system I got a similar bug as minipli/linux-unofficial_grsec#23 :
Who can tell what causes this? What info do I need to provide?... (No leads in the last end of year/start of this year bugs in minipli's unofficial_grsec...)
Upon rebooting the system, all is now fine since then (uptime only 4:00 hours since then. That happened at 09:52 this morning UTC. Now is 14:00 UTC.