tls: handle data disappearing from under the TLS ULP
TLS expects that it owns the receive queue of the TCP socket. This cannot be guaranteed in case the reader of the TCP socket entered before the TLS ULP was installed, or uses some non-standard read API (eg. zerocopy ones). Replace the WARN_ON() and a buggy early exit (which leaves anchor pointing to a freed skb) with real error handling. Wipe the parsing state and tell the reader to retry. We already reload the anchor every time we (re)acquire the socket lock, so the only condition we need to avoid is an out of bounds read (not having enough bytes in the socket for previously parsed record len). If some data was read from under TLS but there's enough in the queue we'll reload and decrypt what is most likely not a valid TLS record. Leading to some undefined behavior from TLS perspective (corrupting a stream? missing an alert? missing an attack?) but no kernel crash should take place. Reported-by:William Liu <will@willsroot.io> Reported-by:
Savino Dicanosa <savy@syst3mfailure.io> Link: https://lore.kernel.org/tFjq_kf7sWIG3A7CrCg_egb8CVsT_gsmHAK0_wxDPJXfIzxFAMxqmLwp3MlU5EHiet0AwwJldaaFdgyHpeIUCS-3m3llsmRzp9xIOBR4lAI=@syst3mfailure.io Fixes: 84c61fe1 ("tls: rx: do not use the standard strparser") Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250807232907.600366-1-kuba@kernel.org Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
Loading
-
mentioned in commit 693ddd47
-
mentioned in commit 2f250ab2
-
mentioned in commit 1fba4090
-
mentioned in commit f4133309
-
mentioned in commit bd8a0c62
-
mentioned in commit 8480d9ba
-
mentioned in commit 2c26f22e
-
mentioned in commit c36031bc
-
mentioned in commit 3376665c
-
mentioned in commit 0fa101af
-
mentioned in commit 316dcd48
-
mentioned in commit d5945435
-
mentioned in commit 70980fd7
-
mentioned in commit da0e471f
-
mentioned in commit 3dc416a2
-
mentioned in commit 124c4f98
-
mentioned in commit 1cf9e074
Please sign in to comment