In the Linux kernel, the following vulnerability has been resolved:
virtioring: Fix data race by tagging eventtriggered as racy for KCSAN
syzbot reports a data-race when accessing the event_triggered, here is the simplified stack when the issue occurred:
================================================================== BUG: KCSAN: data-race in virtqueuedisablecb / virtqueueenablecb_delayed
write to 0xffff8881025bc452 of 1 bytes by task 3288 on cpu 0: virtqueueenablecbdelayed+0x42/0x3c0 drivers/virtio/virtioring.c:2653 startxmit+0x230/0x1310 drivers/net/virtionet.c:3264 _netdevstartxmit include/linux/netdevice.h:5151 [inline] netdevstartxmit include/linux/netdevice.h:5160 [inline] xmitone net/core/dev.c:3800 [inline]
read to 0xffff8881025bc452 of 1 bytes by interrupt on cpu 1: virtqueuedisablecbsplit drivers/virtio/virtioring.c:880 [inline] virtqueuedisablecb+0x92/0x180 drivers/virtio/virtioring.c:2566 skbxmitdone+0x5f/0x140 drivers/net/virtionet.c:777 vringinterrupt+0x161/0x190 drivers/virtio/virtioring.c:2715 _handleirqeventpercpu+0x95/0x490 kernel/irq/handle.c:158 handleirqevent_percpu kernel/irq/handle.c:193 [inline]
When the data race occurs, the function virtqueueenablecbdelayed() sets eventtriggered to false, and virtqueuedisablecbsplit/packed() reads it as false due to the race condition. Since eventtriggered is an unreliable hint used for optimization, this should only cause the driver temporarily suggest that the device not send an interrupt notification when the event index is used.
Fix this KCSAN reported data-race issue by explicitly tagging the access as data_racy.