CVE-2026-46015

Vulnérabilité élevée dans Linux (Linux)

CVSS 7.8 · Élevée
EPSS 0.1%
Linux•Linux•Versions : 7.0.4, <=6.1.*, <=7.0.*, <=6.12.*, 0, 6.18.27, <83bb57635d7cbafde32f865b577ecfd969f02337, <bebd058ef40c67a81fe6d9ee8beaa4ede90e0704, <5.14, 5.15.209, <=6.6.*, 5.14, 6.1.175, <12625b4da84caf4d84a04988710a7b9bcf702b18, 7.1, <=6.18.*, <3864c6ba1e041bc75342353a70fa2a2c6f909923, <ab5fdcd535645f6dbe6e9e21d96a08d141e88b4b, <=*, 54b92e84193749c9968aff2dd46e3b0f42643e18, <=5.15.*, <7aa7933a5607b1e5b56f322d17265c1d0ea02c51, 6.6.140, 6.12.86, <14e9bb6eba8f59dcc637702e4744ae5e30660d76

Description

In the Linux kernel, the following vulnerability has been resolved: tcp: call sk_data_ready() after listener migration When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly.

Gravité et risque d'exploitation

CVE-2026-46015 obtient un score CVSS de 7.8/10, soit une gravité élevée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.14 %, ce qui la place devant 2.7 % des CVE référencées.

Que faire ?

  • Vérifiez si Linux (versions 7.0.4, <=6.1.*, <=7.0.*, <=6.12.*, 0, 6.18.27, <83bb57635d7cbafde32f865b577ecfd969f02337, <bebd058ef40c67a81fe6d9ee8beaa4ede90e0704, <5.14, 5.15.209, <=6.6.*, 5.14, 6.1.175, <12625b4da84caf4d84a04988710a7b9bcf702b18, 7.1, <=6.18.*, <3864c6ba1e041bc75342353a70fa2a2c6f909923, <ab5fdcd535645f6dbe6e9e21d96a08d141e88b4b, <=*, 54b92e84193749c9968aff2dd46e3b0f42643e18, <=5.15.*, <7aa7933a5607b1e5b56f322d17265c1d0ea02c51, 6.6.140, 6.12.86, <14e9bb6eba8f59dcc637702e4744ae5e30660d76) est présent sur votre parc.
  • Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
  • À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
  • Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.

Références