CVE-2026-72491
CVE CVE-2026-72491EUVD EUVD-2026-59390Veröffentlicht 2026-08-15T05:57:26.000ZZuletzt geändert 2026-08-17T05:44:52.000ZCVSS 9.8
Was das Advisory beschreibt
In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.
Quelle: EUVD (ENISA), im Wortlaut der Meldung.
Produkte, die das Advisory nennt
Diese Angaben stammen aus der Meldung selbst, nicht aus einer Prüfung durch uns.
- Linux — Linux 4.19.57 <4.20; patch: 5.15.212; patch: 0; 3479b3c35e82ed10aa0ca2ee9e78c4eded06ba62; patch: 6.6.145; 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b <4cee2b8766045059d5e0b8114837b4a8efe827ac; 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b <8aadc136d8e8d8fc95d7982d213cfe2234dfcf2b; 4.4.185 <4.5; patch: 6.1.178; e48e7e27e4dfd00c81e0381e7cee610cce021452; 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b <3970a19a80de530b801b6256354d4a529a9a2d6c; 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b <ebbcbe5c0db215feecc17def06178da443f4eea6; 9e69c673fe077b8dc491cd8406c9bdcb1f76dee2; 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b <151f8cf5b23d8a534d884432a82a6d54d5a61989; 4.9.185 <4.10; patch: 7.2; patch: 7.1.5; c01ddaa54d7411e964ffd250c018d8469c5852f2; patch: 6.18.40; 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b <7d54894a1ee265a72d70f7cae1da6cc774cccc71; 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b <13bf9879b778b2f4b260b45bed18f31806120d1e; patch: 6.12.97; 4.20; 4.14.132 <4.15; 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b <5424138848eb7d7d8a7196676e90a2cbf2142454; patch: 5.10.261
Die genannten Versionen sind die Angabe der Meldung. Patchlage vergleicht keine Versionsnummern und leitet aus ihnen keine Aussage ab — welche Version installiert ist, muss ein Mensch nachsehen.
Im Produktkatalog geführt
Für diese Produkte kann ein Bestand in Patchlage erfasst werden. Ein Advisory dazu erscheint am Morgen danach im Lagebericht.
- Linux — Linux
Betrifft das einen Ihrer Kundenbestände?
Diese Seite kann die Frage nicht beantworten — sie kennt Ihren Bestand nicht. Wer seine Umgebungen erfasst hat, bekommt die Antwort am Morgen nach der Veröffentlichung, zusammen mit einem Absatz, den er unverändert an den Kunden weitergeben kann.
28 Tage testenPatchlage meldet Treffer und Verdachtsfälle. Zu allem anderen sagt dieses System nichts — weder diese Seite noch der Lagebericht behauptet je, dass ein Bestand sicher ist.