FlawAtlas
Search the atlas
CVE-2025-38616 Not scored

tls: handle data disappearing from under the TLS ULP

In the Linux kernel, the following vulnerability has been resolved: 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.

Exploit probability 0.2%
Published August 22, 2025
Required by Not available
Last source change July 15, 2026

02 / AFFECTED SOFTWARE

Affected packages

Android :linux_kernel:

1 explicit affected versions

Unknown Unknown
Linux Kernel

03 / CONNECTIONS

Connected vulnerabilities

related OPENSUSE-SU-2025:20081-1
related SUSE-SU-2025:03600-1
related SUSE-SU-2025:03601-1
related SUSE-SU-2025:03633-1
related SUSE-SU-2025:03634-1
related SUSE-SU-2025:20851-1
related SUSE-SU-2025:20861-1
related SUSE-SU-2025:20870-1
related SUSE-SU-2025:20898-1
related SUSE-SU-2025:21074-1
related SUSE-SU-2025:21085-1
related SUSE-SU-2025:21086-1
related SUSE-SU-2025:21087-1
related SUSE-SU-2025:21088-1
related SUSE-SU-2025:21089-1
related SUSE-SU-2025:21090-1
related SUSE-SU-2025:21091-1
related SUSE-SU-2025:21092-1
related SUSE-SU-2025:21093-1
related SUSE-SU-2025:21094-1
related SUSE-SU-2025:21095-1
related SUSE-SU-2025:21096-1
related SUSE-SU-2025:21097-1
related SUSE-SU-2025:21098-1
related SUSE-SU-2025:21099-1
related SUSE-SU-2025:21100-1
related SUSE-SU-2025:21101-1
related SUSE-SU-2025:21102-1
related SUSE-SU-2025:21103-1
related SUSE-SU-2025:21104-1
related SUSE-SU-2025:21107-1
related SUSE-SU-2025:21108-1
related SUSE-SU-2025:21109-1
related SUSE-SU-2025:21110-1
related SUSE-SU-2025:21111-1
related SUSE-SU-2025:21112-1
related SUSE-SU-2025:21113-1
related SUSE-SU-2025:21114-1
related SUSE-SU-2025:21115-1
related SUSE-SU-2025:21116-1
related SUSE-SU-2025:21117-1
related SUSE-SU-2025:21118-1
related SUSE-SU-2025:21119-1
related SUSE-SU-2025:21120-1
related SUSE-SU-2025:21121-1
related SUSE-SU-2025:21122-1
related SUSE-SU-2025:21123-1
related SUSE-SU-2025:21124-1
related SUSE-SU-2025:21139-1
related SUSE-SU-2025:21179-1
related SUSE-SU-2025:3725-1
related SUSE-SU-2025:3751-1
related SUSE-SU-2025:4160-1
related SUSE-SU-2025:4161-1
related SUSE-SU-2025:4164-1
related SUSE-SU-2025:4167-1
related SUSE-SU-2025:4169-1
related SUSE-SU-2025:4200-1
related SUSE-SU-2025:4201-1
related SUSE-SU-2025:4208-1
related SUSE-SU-2025:4261-1
related SUSE-SU-2025:4262-1
related SUSE-SU-2025:4265-1
related SUSE-SU-2025:4268-1
related SUSE-SU-2025:4269-1
related SUSE-SU-2025:4275-1
related SUSE-SU-2025:4282-1
related SUSE-SU-2025:4302-1
related SUSE-SU-2025:4306-1
related SUSE-SU-2025:4311-1
related SUSE-SU-2026:20149-1
related SUSE-SU-2026:20164-1
related SUSE-SU-2026:20169-1

04 / EVIDENCE

Source records

Open Source Vulnerabilities ASB-A-440544812

In multiple locations, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

View original source
Open Source Vulnerabilities CVE-2025-38616

In the Linux kernel, the following vulnerability has been resolved: 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.

View original source

05 / REFERENCES

Further evidence