bad packet ID on TCP

[LGA1150]

When testing TCP I got random disconnects, whose error code is either ECONNRESET or EPIPE

tun0: TCP error to peer 0: -104
tun0: deleting peer with id 0, reason 1
IPv6: ADDRCONF(NETDEV_CHANGE): tun0: link becomes ready
tun0: deleting peer with id 0, reason 1
IPv6: ADDRCONF(NETDEV_CHANGE): tun0: link becomes ready
tun0: TCP error to peer 0: -104
tun0: deleting peer with id 0, reason 3
IPv6: ADDRCONF(NETDEV_CHANGE): tun0: link becomes ready

The server side detected bad packet ID and closed the connection

openvpn[744]: myclient1/192.168.8.2:37362 AEAD Decrypt error: bad packet ID (may be a replay): [ #153657 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
openvpn[744]: myclient1/192.168.8.2:37362 Fatal decryption error (process_incoming_link), restarting
openvpn[744]: myclient1/192.168.8.2:37362 SIGUSR1[soft,decryption-error] received, client-instance restarting

Sometimes the disconnects trigger a known issue as in #1

tun0: TCP error to peer 0: -32
IPv6: ADDRCONF(NETDEV_CHANGE): tun0: link becomes ready
tun0: TCP error to peer 0: -104
tun0: deleting peer with id 0, reason 3
==================================================================
BUG: KASAN: use-after-free in ovpn_socket_release+0x142/0x2d0 [ovpn]
Read of size 8 at addr ffffffe003bf3718 by task kworker/1:0/16

CPU: 1 PID: 16 Comm: kworker/1:0 Not tainted 5.10.104+ #0
Workqueue: events ovpn_peer_keepalive_work [ovpn]
Call Trace:
[<ffffffe0000460d0>] walk_stackframe+0x0/0x1d0
[<ffffffe00004642a>] show_stack+0x2e/0x44
[<ffffffe0003dc710>] dump_stack+0xc2/0x102
[<ffffffe000222fc6>] print_address_description.constprop.0+0x6c/0x466
[<ffffffe00022362a>] kasan_report+0x14a/0x170
[<ffffffe000223b32>] __asan_load8+0x62/0x90
[<ffffffe00600e272>] ovpn_socket_release+0x142/0x2d0 [ovpn]
[<ffffffe0060093ae>] unlock_ovpn+0x6e/0x190 [ovpn]
[<ffffffe00600dc22>] ovpn_peer_keepalive_work+0x182/0x270 [ovpn]
[<ffffffe000085162>] process_one_work+0x502/0xaa0
[<ffffffe0000857b0>] worker_thread+0xb0/0x850
[<ffffffe000091826>] kthread+0x1e6/0x210
[<ffffffe000042ca4>] ret_from_kernel_thread+0x8/0xc

Allocated by task 3108:
 save_stack_trace+0x1a/0x2e
 stack_trace_save+0x84/0xa0
 kasan_save_stack+0x26/0x70
 __kasan_kmalloc.isra.0+0xf6/0x100
 kasan_slab_alloc+0x12/0x20
 kmem_cache_alloc+0x164/0x2d0
 sock_alloc_inode+0x20/0xd0
 new_inode_pseudo+0x28/0xa0
 __sock_create+0x54/0x590
 __sys_socket+0xa6/0x350
 sys_socket+0x12/0x20
 ret_from_syscall+0x0/0x2

Freed by task 0:
 save_stack_trace+0x1a/0x2e
 stack_trace_save+0x84/0xa0
 kasan_save_stack+0x26/0x70
 kasan_set_track+0x18/0x30
 kasan_set_free_info+0x1a/0x40
 __kasan_slab_free+0xf8/0x140
 kasan_slab_free+0xe/0x20
 kmem_cache_free+0x82/0x3d0
 sock_free_inode+0x1e/0x40
 i_callback+0x22/0x60
 rcu_core+0x408/0xb70
 rcu_core_si+0xc/0x20
 __do_softirq+0x1f8/0x85c

Last call_rcu():
 save_stack_trace+0x1a/0x2e
 stack_trace_save+0x84/0xa0
 kasan_save_stack+0x26/0x70
 kasan_record_aux_stack+0xa8/0xc0
 call_rcu+0x5c/0x590
 destroy_inode+0x80/0xb0
 evict+0x1dc/0x280
 iput+0x2d6/0x390
 dentry_unlink_inode+0x156/0x1a0
 __dentry_kill+0x13c/0x250
 dput+0x3bc/0x570
 __fput+0x134/0x310
 ____fput+0xc/0x20
 task_work_run+0x9a/0x100
 do_notify_resume+0x140/0x630
 work_notifysig+0xc/0xe

Second to last call_rcu():
 save_stack_trace+0x1a/0x2e
 stack_trace_save+0x84/0xa0
 kasan_save_stack+0x26/0x70
 kasan_record_aux_stack+0xa8/0xc0
 call_rcu+0x5c/0x590
 destroy_inode+0x80/0xb0
 evict+0x1dc/0x280
 iput+0x2d6/0x390
 dentry_unlink_inode+0x156/0x1a0
 __dentry_kill+0x13c/0x250
 dput+0x3bc/0x570
 __fput+0x134/0x310
 ____fput+0xc/0x20
 task_work_run+0x9a/0x100
 do_notify_resume+0x140/0x630
 work_notifysig+0xc/0xe

The buggy address belongs to the object at ffffffe003bf3700
 which belongs to the cache sock_inode_cache of size 1152
The buggy address is located 24 bytes inside of
 1152-byte region [ffffffe003bf3700, ffffffe003bf3b80)
The buggy address belongs to the page:
page:00000000b0585366 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x23bf0
head:00000000b0585366 order:3 compound_mapcount:0 compound_pincount:0
flags: 0x10200(slab|head)
raw: 0000000000010200 0000000000000000 0000000000000122 ffffffe0024ceb40
raw: 0000000000000000 0000000080190019 00000001ffffffff
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffffffe003bf3600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffffffe003bf3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffffffe003bf3700: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                            ^
 ffffffe003bf3780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffffffe003bf3800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Disabling lock debugging due to kernel taint
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000384
Oops [#1]
Modules linked in: *
CPU: 1 PID: 16 Comm: kworker/1:0 Tainted: G    B             5.10.104+ #0
Workqueue: events ovpn_peer_keepalive_work [ovpn]
epc : ovpn_socket_release+0x154/0x2d0 [ovpn]
 ra : ovpn_socket_release+0x152/0x2d0 [ovpn]
epc : ffffffe00600e284 ra : ffffffe00600e282 sp : ffffffe0025d7b60
 gp : ffffffe000f0b198 tp : ffffffe0025c8000 t0 : 6e696c6261736944
 t1 : 0000000000000010 t2 : 676e696c62617369 s0 : ffffffe0025d7ba0
 s1 : ffffffe0026c6200 a0 : 0000000000000000 a1 : 0000000000000002
 a2 : 0000000000000000 a3 : ffffffe00600e282 a4 : 0000000000000011
 a5 : 0000000000000000 a6 : ffffffc40019e653 a7 : dfffffc800000000
 s2 : 0000000000000000 s3 : ffffffe003bf3700 s4 : fffffffffffffbb8
 s5 : 0000000000000001 s6 : ffffffe0019a9be0 s7 : 000000006837ce3b
 s8 : ffffffe0025d7c10 s9 : 1ffffffc004baf7e s10: ffffffe006ac6a40
 s11: 0000000000000001 t3 : ffffffe000cf3293 t4 : ffffffc40019e652
 t5 : 1ffffffc0019e652 t6 : ffffffc40019e653
status: 0000000200000120 badaddr: 0000000000000384 cause: 000000000000000d
[<ffffffe00600e284>] ovpn_socket_release+0x154/0x2d0 [ovpn]
[<ffffffe0060093ae>] unlock_ovpn+0x6e/0x190 [ovpn]
[<ffffffe00600dc22>] ovpn_peer_keepalive_work+0x182/0x270 [ovpn]
[<ffffffe000085162>] process_one_work+0x502/0xaa0
[<ffffffe0000857b0>] worker_thread+0xb0/0x850
[<ffffffe000091826>] kthread+0x1e6/0x210
[<ffffffe000042ca4>] ret_from_kernel_thread+0x8/0xc

[ordex]

The server side detected bad packet ID and closed the connection

do you know why this is happening? May this be related to the bitops.h patch you sent earlier on?

Sometimes the disconnects trigger a known issue as in #1

Are you testing the code in the development branch or main?

[LGA1150]

The server side detected bad packet ID and closed the connection

do you know why this is happening?

I think it's related to async crypto handling, like #14. As long as I don't load the hardware crypto driver, it is fine.

May this be related to the bitops.h patch you sent earlier on?

The server side is running without DCO.

Anyway, is it okay to close the connection whenever an invalid packet ID is received? That could be a DoS exploit.

Sometimes the disconnects trigger a known issue as in #1

Are you testing the code in the development branch or main?

main

[ordex]

Anyway, is it okay to close the connection whenever an invalid packet ID is received? That could be a DoS exploit.

well, if the TCP stream is messed up there is not much we can do to recover.