Answer in brief
CVE-2025-40248 records a Unknown severity vulnerability in vsock: Ignore signal/timeout on connect() if already established. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Siemens/RUGGEDCOM RST2428P (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2025-40248 records a Unknown severity vulnerability in vsock: Ignore signal/timeout on connect() if already established. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Siemens/RUGGEDCOM RST2428P (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Siemens/RUGGEDCOM RST2428P (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=d021c344051af91f42c5ba9fdedc176740cbd238 <3f71753935d648082a8279a97d30efe6b85be680 || >=d021c344051af91f42c5ba9fdedc176740cbd238 <da664101fb4a0de5cb70d2bae6a650df954df2af || >=d021c344051af91f42c5ba9fdedc176740cbd238 <67432915145848658149683101104e32f9fd6559 || >=d021c344051af91f42c5ba9fdedc176740cbd238 <eeca93f06df89be5a36305b7b9dae1ed65550dfc || >=d021c344051af91f42c5ba9fdedc176740cbd238 <5998da5a8208ae9ad7838ba322bccb2bdcd95e81 || >=d021c344051af91f42c5ba9fdedc176740cbd238 <f1c170cae285e4b8f61be043bb17addc3d0a14b5 || >=d021c344051af91f42c5ba9fdedc176740cbd238 <ab6b19f690d89ae4709fba73a3c4a7911f495b7a || >=d021c344051af91f42c5ba9fdedc176740cbd238 <002541ef650b742a198e4be363881439bb9d86b4 | 3f71753935d648082a8279a97d30efe6b85be680, da664101fb4a0de5cb70d2bae6a650df954df2af, 67432915145848658149683101104e32f9fd6559, eeca93f06df89be5a36305b7b9dae1ed65550dfc, 5998da5a8208ae9ad7838ba322bccb2bdcd95e81, f1c170cae285e4b8f61be043bb17addc3d0a14b5, ab6b19f690d89ae4709fba73a3c4a7911f495b7a, 002541ef650b742a198e4be363881439bb9d86b4 |
| Linux/Linuxgeneric | 3.9 | Not reported |
| Siemens/RUGGEDCOM RST2428Pgeneric | >=0 <V4.0 | V4.0 |
Published upstream
Dec 4, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/[email protected]/ [2]: https://lore.kernel.org/netdev/[email protected]/ [3]: https://lore.kernel.org/netdev/[email protected]/
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Siemens/RUGGEDCOM RST2428P (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=d021c344051af91f42c5ba9fdedc176740cbd238 <3f71753935d648082a8279a97d30efe6b85be680 || >=d021c344051af91f42c5ba9fdedc176740cbd238 <da664101fb4a0de5cb70d2bae6a650df954df2af || >=d021c344051af91f42c5ba9fdedc176740cbd238 <67432915145848658149683101104e32f9fd6559 || >=d021c344051af91f42c5ba9fdedc176740cbd238 <eeca93f06df89be5a36305b7b9dae1ed65550dfc || >=d021c344051af91f42c5ba9fdedc176740cbd238 <5998da5a8208ae9ad7838ba322bccb2bdcd95e81 || >=d021c344051af91f42c5ba9fdedc176740cbd238 <f1c170cae285e4b8f61be043bb17addc3d0a14b5 || >=d021c344051af91f42c5ba9fdedc176740cbd238 <ab6b19f690d89ae4709fba73a3c4a7911f495b7a || >=d021c344051af91f42c5ba9fdedc176740cbd238 <002541ef650b742a198e4be363881439bb9d86b4 | 3f71753935d648082a8279a97d30efe6b85be680, da664101fb4a0de5cb70d2bae6a650df954df2af, 67432915145848658149683101104e32f9fd6559, eeca93f06df89be5a36305b7b9dae1ed65550dfc, 5998da5a8208ae9ad7838ba322bccb2bdcd95e81, f1c170cae285e4b8f61be043bb17addc3d0a14b5, ab6b19f690d89ae4709fba73a3c4a7911f495b7a, 002541ef650b742a198e4be363881439bb9d86b4 |
| Linux/Linuxgeneric | 3.9 | Not reported |
| Siemens/RUGGEDCOM RST2428Pgeneric | >=0 <V4.0 | V4.0 |
Published upstream
Dec 4, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/[email protected]/ [2]: https://lore.kernel.org/netdev/[email protected]/ [3]: https://lore.kernel.org/netdev/[email protected]/
Quoted source text, attributed separately from HOL analysis.