CVE-2026-64045
Beschrijving NL
In de Linux kernel is de volgende kwetsbaarheid verholpen:
ovpn: tcp - gebruik gecachete peer pointer in ovpn_tcp_close()
ovpn_tcp_close() laadt de ovpn_socket via rcu_dereference_sk_user_data()
onder rcu_read_lock(), neemt een referentie op sok->peer, caches de peer
wijzer in een lokaal en laat de leesvergrendeling vallen. Het passeert dan sok->peer
(in plaats van de lokale cache) naar ovpn_peer_del(), waarbij de
ovpn_socket nadat de RCU-leessectie is beëindigd. In tegenstelling tot ovpn_tcp_sendmsg (), die dezelfde "belasting onder RCU gebruikt, gebruikt u
na ontgrendelen" patroon, maar wordt beschermd door lock_sock() die over de
functie, ovpn_tcp_close() draait zonder de socketvergrendeling: inet_release()
roept sk_prot->close() aan zonder eerst lock_sock te nemen. ovpn_socket_release() kan daarom zijn kref_put -> losmaken ->
synize_rcu -> kfree(sok) sequentie gelijktijdig, in het venster
nadat ovpn_tcp_close() rcu_read_lock() laat vallen, maar voordat het dereferences
sok->peer. De synchronize_rcu() in ovpn_socket_release() beschermt
lezers die de verwijzende aanwijzer in de RCU-leessectie gebruiken,
niet degenen die aan de aanwijzer ontsnappen naar een local en deze daarna gebruiken. Een reproducer volgt het patroon van commit 94560267d6c4 ("ovpn: tcp -
don 't DEREF NULL sk_socket member after tcp_close()"): activeer een peer
verwijdering (keepalive vervaldatum of netlink OVPN_CMD_DEL_PEER) op hetzelfde
moment dat userspace de TCP fd sluit. Die commit bevestigde de loskoppelzijde
van hetzelfde racevenster; deze fixeert de close-side op een andere
slachtoffer. Draai het invoerblok vast om sok te lezen- >tuur precies één keer in de cache
peer lokaal, en routeer alle daaropvolgende toepassingen (de controle van de hold, de
ovpn_peer_del() oproep, en de prot->close() aanroep) via die
local. sock->peer wordt slechts één keer geschreven in ovpn_socket_new() onder
lock_sock(), voordat rcu_assign_sk_user_data() de ovpn_socket publiceert,
en wordt daarna nooit opnieuw toegewezen - maar het vorige multi-read-patroon
maakte dat invariant impliciet in plaats van expliciet. Dezelfde multi-read
vorm bestaat in ovpn_tcp_recvmsg(), ovpn_tcp_sendmsg(),
ovpn_tcp_data_ready() en ovpn_tcp_write_space(); deze worden schoongemaakt
via een toegewijde helper in een follow-up net-next-serie.
Origineel (Engels) tonen
In the Linux kernel, the following vulnerability has been resolved:
ovpn: tcp - use cached peer pointer in ovpn_tcp_close()
ovpn_tcp_close() loads the ovpn_socket via rcu_dereference_sk_user_data()
under rcu_read_lock(), takes a reference on sock->peer, caches the peer
pointer in a local, and drops the read lock. It then passes sock->peer
(rather than the cached local) to ovpn_peer_del(), re-dereferencing the
ovpn_socket after the RCU read section has ended.
Unlike ovpn_tcp_sendmsg(), which uses the same "load under RCU, use
after unlock" pattern but is protected by lock_sock() held across the
function, ovpn_tcp_close() runs without the socket lock: inet_release()
invokes sk_prot->close() without taking lock_sock first.
ovpn_socket_release() can therefore complete its kref_put -> detach ->
synchronize_rcu -> kfree(sock) sequence concurrently, in the window
after ovpn_tcp_close() drops rcu_read_lock() but before it dereferences
sock->peer. The synchronize_rcu() in ovpn_socket_release() protects
readers that use the dereferenced pointer inside the RCU read section,
not those that escape the pointer to a local and use it afterwards.
A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp -
don't deref NULL sk_socket member after tcp_close()"): trigger a peer
removal (keepalive expiration or netlink OVPN_CMD_DEL_PEER) at the same
moment userspace closes the TCP fd. That commit fixed the detach-side
of the same race window; this one fixes the close-side at a different
victim.
Tighten the entry block to read sock->peer exactly once into the cached
peer local, and route all subsequent uses (the hold check, the
ovpn_peer_del() call, and the prot->close() invocation) through that
local. sock->peer is only ever written once in ovpn_socket_new() under
lock_sock(), before rcu_assign_sk_user_data() publishes the ovpn_socket,
and is never reassigned afterwards - but the previous multi-read pattern
made that invariant implicit rather than explicit. The same multi-read
shape exists in ovpn_tcp_recvmsg(), ovpn_tcp_sendmsg(),
ovpn_tcp_data_ready() and ovpn_tcp_write_space(); those will be cleaned
up via a dedicated helper in a follow-up net-next series.