At any point of the digital transition,…
Friday, October 23, 2020, 22:48 GMT
In the Linux kernel through 5.9.1, as used for Xen through 4.14.x, a problem was found. Drivers / xen / events / events base.c requires event-channel exclusion (a race condition) during the event-handling loop. As shown by a dom0 crash via events for an in-reconfiguration paravirtualized computer, aka CID-073d0552ead5, this can cause a use-after-free or NULL pointer dereference.
xen / events: stop disabling an event channel when it is being handled
Today, an event channel can be excluded from the event channel.
Device when the loop is working for the event handling. This will result in aRace that results in crashes or splats of WARN) (while attempting to reach The layout of irq info applies to the event channel. Using a rwlock taken as a reader in the case to correct this issue loop handling and as a writer as the irq info structure is allocated.
A NULL dereference in evtchn from irq) (was the observed concern. Checking the irq details to make this feature more stable against races before dereferencing it, the pointer should not be Empty.
Finally , make all accesses to atomic ones evtchn to irq[row][col] To prevent the partial updating of an array feature in irq from being seen dealing. Notice that it is possible to join irq handling for event channels only which were previously real, so any row not populated is not an issue