CVE-2026-80895

CVE CVE-2026-80895EUVD EUVD-2026-71645Veröffentlicht 2026-09-04T17:11:10.000Z

Was das Advisory beschreibt

In the Linux kernel, the following vulnerability has been resolved: mshv: Order pt_vp_array publish against irqfd assertion path mshv_partition_ioctl_create_vp() initialises a VP struct (allocations, mutex_init, init_waitqueue_head, page mappings) and then publishes the pointer into partition->pt_vp_array. Several ISR paths read this array locklessly: the intercept ISR, the two scheduler ISRs, and mshv_try_assert_irq_fast() on the irqfd fast path. Of these, only mshv_try_assert_irq_fast() can structurally race the publish. It runs from an eventfd waker without holding pt_mutex, and MSHV_IRQFD does not require the target lapic_apic_id (== vp_index) to refer to an existing VP at registration time. A user can therefore register an irqfd targeting a yet-to-be-created VP, then trigger mshv_try_assert_irq_fast() concurrently with MSHV_CREATE_VP for the same index. On weakly-ordered architectures the reader can observe a non-NULL pointer in pt_vp_array before the initialising stores to the VP struct become visible, leading to use of partially-initialised fields (e.g. vp_register_page). The other ISR readers cannot reach this race: the hypervisor will not generate intercept or scheduler messages for a VP that has never been told to run, and the user can only call MSHV_RUN_VP on the VP fd returned by MSHV_CREATE_VP, which by construction is returned after the publish. Leave those readers as plain loads. Use smp_store_release() in mshv_partition_ioctl_create_vp() to publish the pointer, and pair it with smp_load_acquire() in mshv_try_assert_irq_fast(). On x86 these compile to plain accesses under TSO; on ARM64 they emit one-instruction acquire/release barriers, acceptable on this fast path. The destroy-side path (destroy_partition() clearing pt_vp_array[i] to NULL after kfree(vp)) has a separate ordering and lifetime concern that is out of scope here.

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 patch: 7.2; patch: 0; 6.15; 621191d709b14882270dfd8ea5d7d6cdfebe2c35 <b098dc869219c15dc49bf9cf63fb5fc1481d3373; 621191d709b14882270dfd8ea5d7d6cdfebe2c35 <062aa5dcc49a9ad96726a80c2a0ab0a1233bc2b9; patch: 6.18.44; 621191d709b14882270dfd8ea5d7d6cdfebe2c35 <eba2bf5daa7933f94c53ebbbf0f567d4274716df; patch: 7.1.8

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

Patchlage 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.