summaryrefslogtreecommitdiff
path: root/scripts/Makefile.thinlto
diff options
context:
space:
mode:
authorSungho Bae <baver.bae@lge.com>2026-06-04 03:37:56 +0900
committerMichael S. Tsirkin <mst@redhat.com>2026-09-04 17:06:04 -0400
commit8d2b35741ec0b9546f2e309e4804c95984f30d6c (patch)
tree4cdd3a936bb1172214b91ebc06df2fe26193195d /scripts/Makefile.thinlto
parente17b6c1e54e9324386d92cd868d15814f1d683f1 (diff)
downloadlinux-next-8d2b35741ec0b9546f2e309e4804c95984f30d6c.tar.gz
linux-next-8d2b35741ec0b9546f2e309e4804c95984f30d6c.zip
virtio_console: fix control queue race during restore
In virtcons_restore(), after virtio_device_ready() sets DRIVER_OK, the device becomes active. If the control receive queue (c_ivq) is populated immediately, the host can instantly deliver pending control messages (e.g., VIRTIO_CONSOLE_PORT_REMOVE). This triggers the control_work_handler(), which can modify the portdev->ports list concurrently with the unprotected list_for_each_entry loop in virtcons_restore(), leading to list corruption or Use-After-Free. Fix this by deferring the population of the control receive queue (fill_queue for c_ivq) until after the list iteration is complete. This ensures the host cannot inject control messages during the vulnerable window. Signed-off-by: Sungho Bae <baver.bae@lge.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260603183757.21587-4-baver.bae@gmail.com>
Diffstat (limited to 'scripts/Makefile.thinlto')
0 files changed, 0 insertions, 0 deletions