Kernel core dump analysis:

crash> set 
PID: 23697 
COMMAND: "kworker/u82:0" 
TASK: 88370bcfaa80 [THREAD_INFO: 883708104000] 
CPU: 33 
STATE: TASK_RUNNING (PANIC) 

crash> bt 
PID: 23697 TASK: 88370bcfaa80 CPU: 33 COMMAND: "kworker/u82:0" 
[...] 
#3 [883708107b78] __bad_area_nosemaphore at 8106a889 
#4 [883708107bc0] bad_area_nosemaphore at 8106a9a3 
#5 [883708107bd0] __do_page_fault at 8106aff2 
#6 [883708107c30] trace_do_page_fault at 8106b3f7 
#7 [883708107c60] do_async_page_fault at 81063e19 
#8 [883708107c70] async_page_fault at 81822958 
#9 [883708107cf8] n_tty_receive_buf_common at 814e676a 
#10 [883708107dc8] n_tty_receive_buf2 at 814e71f4 
#11 [883708107dd8] flush_to_ldisc at 814e9be5 
#12 [883708107e20] process_one_work at 8109b0b6 
#13 [883708107e68] worker_thread at 8109ba9a 
[...] 

crash> bt -f 
[...] 
#9 [883708107cf8] n_tty_receive_buf_common at 814e676a 
[...] 
883708107d80: 881bc78e4c20 0000000000000000 
883708107d90: 0000000000000014 881bc78e4c00 
883708107da0: 881bc78e7800 881cba173d80 
883708107db0: 883706cae828 883706cae808 
883708107dc0: 883708107dd0 814e71f4 
#10 [883708107dc8] n_tty_receive_buf2 at 814e71f4 
[...] 

From the stack frame, we can infer that "struct tty_struct" is at 
0x881bc78e7800 : 

crash> tty_struct -x 881bc78e7800 | grep name 
name = "pts3\000... 

Also, from the stack frame we see a value 0x14 there, which represents 
the count value in the function: 

static int n_tty_receive_buf2(struct tty_struct *tty, const unsigned char *cp, 
char *fp, int count) 
{ 
return n_tty_receive_buf_common(tty, cp, fp, count, 1); 
} 

Since 0x14 mean 20 in decimal, I'd expect a 20 characters string, 
which turns to be true ( char *cp is at 881bc78e4c20): 

crash> rd -a 881bc78e4c20 
881bc78e4c20: source /root/openrc 

Something is issuing the command "source /root/openrc" to PTS/3. 

Checking the "files" command, we get: 

crash> foreach files -R dev/pts/3 
PID: 2288 TASK: 883786e2ea40 CPU: 29 COMMAND: "sshd" 
ROOT: / CWD: / 
FD FILE DENTRY INODE TYPE PATH 
9 8839b4ce9a00 881a0ba4da40 8838f71fcf88 CHR /dev/pts/3 

And checking ssh processes: 

crash> ps|grep ssh 
2236 7180 18 8836f9dd2a80 IN 0.0 149480 8636 sshd 
2275 2274 37 883706e01540 IN 0.0 37836 4940 ssh 
2288 2236 29 883786e2ea40 UN 0.0 149480 1372 sshd 
7180 1 17 881cb99b6a40 IN 0.0 57204 5240 sshd 
14319 7180 2 8836dfd91540 IN 0.0 149480 8460 sshd 

All except 2288 are scheduled after a select() syscall. 
PID 2288 looks interesting: 

crash> bt 2288 
PID: 2288 TASK: 883786e2ea40 CPU: 29 COMMAND: "sshd" 
[...] 
#4 [88373e0bfb48] down_write at 8181e42d 
#5 [88373e0bfb60] tty_unthrottle at 814e75be 
#6 [88373e0bfb80] n_tty_open at 814e4fb9 
#7 [88373e0bfba0] tty_ldisc_open at 814e8bd5 
#8 [88373e0bfbc0] tty_ldisc_reinit at 814e9112 
#9 [88373e0bfbf0] tty_reopen at 814df50a 
#10 [88373e0bfc08] tty_open at 814e318e 
#11 [88373e0bfc70] chrdev_open at 8120d5c4 
#12 [88373e0bfcb0] do_dentry_open at 81206a6a 
#13 [88373e0bfcf8] vfs_open at 81207b35 
#14 [88373e0bfd20] path_openat at 81215fed 
[...] 

This is the one that seems to be racing with the flush_work from CPU 33 
that led to the crash. 
Since we have the tty_reopen() in the call trace, it's clear it's re-opening 
an existing tty after it was closed, but the flush work was running and 
the crash happened.