diff options
| author |  Sabrina Dubroca <sd@queasysnail.net>
| 2024-02-28 23:43:58 +0100 |
|---|---|---|
| committer |  Jakub Kicinski <kuba@kernel.org>
| 2024-02-29 09:07:16 -0800 |
| commit | 6caaf104423d809b49a67ee6500191d063b40dc6 (patch) | |
| tree | f852685e093a9ddc7dc2fe3ba4184b1cd647206c /net/tls/tls_strp.c | |
| parent | tls: decrement decrypt_pending if no async completion will be called (diff) | |
| download | linux-6caaf104423d809b49a67ee6500191d063b40dc6.tar.gz linux-6caaf104423d809b49a67ee6500191d063b40dc6.tar.bz2 linux-6caaf104423d809b49a67ee6500191d063b40dc6.zip | |
tls: fix peeking with sync+async decryption
If we peek from 2 records with a currently empty rx_list, and the
first record is decrypted synchronously but the second record is
decrypted async, the following happens:
1. decrypt record 1 (sync)
2. copy from record 1 to the userspace's msg
3. queue the decrypted record to rx_list for future read(!PEEK)
4. decrypt record 2 (async)
5. queue record 2 to rx_list
6. call process_rx_list to copy data from the 2nd record
We currently pass copied=0 as skip offset to process_rx_list, so we
end up copying once again from the first record. We should skip over
the data we've already copied.
Seen with selftest tls.12_aes_gcm.recv_peek_large_buf_mult_recs
Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Link: https://lore.kernel.org/r/1b132d2b2b99296bfde54e8a67672d90d6d16e71.1709132643.git.sd@queasysnail.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'net/tls/tls_strp.c')
0 files changed, 0 insertions, 0 deletions