If the frontend pass a bad index of production request, the backend will enter an endless loop and then cause a excessive CPU consumption.

This issue has been fixed in upstream by: changeset: 391:77f831cbb91d user: Keir Fraser <keir.fraser> date: Fri Jan 18 16:52:25 2008 +0000 summary: blkback: Request-processing loop is unbounded and hence requires a http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/77f831cbb91d

changeset: 392:7070d34f251c user: Keir Fraser <keir.fraser> date: Mon Jan 21 11:43:31 2008 +0000 summary: blkback/blktap: Check for kthreadshouldstop() in inner loop, http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/7070d34f251c

Version-Release number of selected component (if applicable): 2.6.18-194.el5xen

How reproducible:

Steps to Reproduce: 1. build a guest kernel with the patch attached. 2. run domU with the patched kernel

Actual results: Dom0 got hung.

Expected results: Dom0 shouldn't be impacted by a bad guest.

Last updated 24 July 2024

The fixuppagefault function in arch/x86/traps.c in Xen 4.0.1 and earlier on 64-bit platforms, when paravirtualization is enabled, does not verify that kernel mode is used to call the handlegdtldtmappingfault function, which allows guest OS users to cause a denial of service (host OS BUGON) via a crafted memory access.