Към съдържанието
Търсене

CVE-2026-23394: Linux

Няма оценка

CVSS

Няма данни

Вероятност да бъде експлоатирана в следващите 30 дни (EPSS)

Няма потвърждение

Атакува се

Няма данни

Време до експлоатация

    Описание

    Оригинално описание

    In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK w

    Засегнати продукти

    • Linux Linux: 61a75360dca93c945ef6bd757f8b8a96f39b77cb преди 980999a96e1ad043f1197606e5d637219cb102b9; 7b1ffbd3b22e755d481d49647dcb7c5cfbde5844 преди 3106f326f67c03dd9da4ca64663d11e40138cf40; 118f457da9ed58a79e24b73c2ef0aa1987241f0e преди e3dd56fb5683ba80bf8d7a2f9aa21cfa53f05202; 118f457da9ed58a79e24b73c2ef0aa1987241f0e преди 72cf49ad50c16270b52bc512d9c2df5743922968; 118f457da9ed58a79e24b73c2ef0aa1987241f0e преди 37dd7ab332396eb8dd80b2dc7ea4b61abf767436; 118f457da9ed58a79e24b73c2ef0aa1987241f0e преди e5b31d988a41549037b8d8721a3c3cae893d8670; 6.1.141 преди 6.1.183; 6.6.93 преди 6.6.142
    • Linux Linux: 6.10; преди 6.10; 6.1.183 до 6.1.*; 6.6.142 до 6.6.*; 6.12.92 до 6.12.*; 6.18.23 до 6.18.*; 6.19.10 до 6.19.*; от 7.0 нататък

    История

    • 25 март 2026 Публикувано

    Други уязвимости в Linux Linux

    Първоизточници

    CVE-2026-23394: Linux | freedomonline.bg