netdev - IPSec ESN: Packets decryption fail with ESN enabled connection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 26 Dec 2018 14:54:05 +0530
From:   Harsh Jain <harsh@...lsio.com>
To:     steffen.klassert@...unet.com, herbert@...dor.apana.org.au,
        davem@...emloft.net, netdev@...r.kernel.org,
        linux-crypto@...r.kernel
Cc:     atul.gupta@...lsio.com, harshjain.prof@...il.com
Subject: IPSec ESN: Packets decryption fail with ESN enabled connection

Hi All,

Kernel version on both machines: 4.19.7.

Packet drops with EBADMSG is observed on receive end of connection. It seems that sometimes crypto driver receives packet with wrong "seq_hi" value in AAD. See below the dump of assoc data for 1 such instance.

[  380.823454] assoclen 8th byte 1 clen 1464 op 1  ==> High byte of ESN
[  380.828398] authsize 12 cryptlen 1464
[  380.832637] dt00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 ==> Decrypted data seems correct,last byte is proto(06 TCP)
[  380.840215] dt00000010: bf ee 4f 80 a4 7f 2a 50 6a 5a 0b 10
[  380.846636] ass00000000: 0a bc d3 31 <00 00 00 01> 00 1c e5 ec 0e af 04 69 ==> ESN-Hi = 1
[  380.854316] ass00000010: a4 fc 08 ad

Note: If I decrypt the same packet with ESN - Hi = 0. It Decrypt successfully means peer machine has used ESN-HI = 0 while encrypting.

To debug further we added trace in "xfrm_replay_seqhi". Following was the output:

 <idle>-0     [003] ..s.   380.967766: xfrm_replay_seqhi: seq_hi 0x 1 seq 0x 1ce5ec bottom 0x 1ce5ee replay seq 0x 1ce62d replay window 0x 40

1) Is this an expected variable with ESN enables connection?.

2) If packets are supposed to be dropped can't we avoid decryption overhead.

Following logs are attached

1) dmesg log

2) debug patch used to reproduce the issue.

3) ftace log file

4) ip xfrm state list

Regards

Harsh Jain

View attachment "dmesg.log" of type "text/plain" (8359 bytes)

View attachment "patch.diff" of type "text/plain" (4736 bytes)

View attachment "trace" of type "text/plain" (6451 bytes)

View attachment "xfrm_list_where_drop_happen.log" of type "text/plain" (1362 bytes)