xend in Xen 3.3.0 does not properly restrict a guest VM's write access within the /local/domain xenstore directory tree, which allows guest OS users to cause a denial of service and possibly have unspecified other impact by writing to (1) console/tty, (2) console/limit, or (3) image/device-model-pid. NOTE: this issue exists because of erroneous setpermissions calls in the fix for CVE-2008-4405.
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
Description of problem: Dom0 crashes when installing GPLPV drivers on Windows 2008 R2 guest.
Xen version: 3.1.2-194.11.3.el5 Dom0 kernel: 2.6.18-194.11.3.el5xen GPLPV: gplpvVista2008x640.11.0.213.msi and older
Redirected to serial console output:
Unable to handle kernel NULL pointer dereference at 0000000000000108 RIP: [<ffffffff8883f03f>] :blkbk:updateblkifstatus+0x21f/0x2ae PGD 0 Oops: 0000 [1] SMP last sysfs file: /class/net/lo/ifindex CPU 2 Modules linked in: tun xfs ocfs2(U) iptMASQUERADE netloop iptablenat ipnat netbk blktap blkbk mptctl mptbase ipmiwatchdog ipmisi(U) ipmidevintf(U) ipmimsghandler(U) autofs4 hidp l2cap bluetooth ocfs2dlmfs(U) ocfs2dlm(U) ocfs2nodemanager(U) configfs lockd sunrpc bonding ipconntracknetbiosns iptREJECT xtstate ipconntrack nfnetlink xtphysdev bridge iptablefilter iptables ip6tREJECT xttcpudp ip6tablefilter ip6tables xtables ipv6 xfrmnalgo cryptoapi be2iscsi ibiser rdmacm ibcm iwcm ibsa ibmad ibcore ibaddr iscsitcp bnx2i(U) cnic(U) cxgb3i cxgb3 libiscsitcp libiscsi2 scsitransportiscsi2 scsitransportiscsi loop dmroundrobin dmmultipath scsidh video backlight sbs powermeter hwmon i2cec i2ccore dellwmi wmi button battery asusacpi ac parportpc lp parport srmod cdrom sg serioraw pcspkr hpilo serialcore bnx2x(U) 8021q dmraid45 dmmessage dmregionhash dmmemcache dmsnapshot dmzero dmmirror dmlog dmmod usbstorage shpchp cciss(U) sdmod scsimod ext3 jbd uhcihcd ohcihcd ehcihcd Pid: 69, comm: xenwatch Tainted: G 2.6.18-194.11.3.el5xen 0000001 RIP: e030:[<ffffffff8883f03f>] [<ffffffff8883f03f>] :blkbk:updateblkifstatus+0x21f/0x2ae RSP: e02b:ffff88003e413df0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88003db2f620 RCX: 0000000000000003 RDX: ffffffffff578000 RSI: fffffffffffffffb RDI: 0000000000000000 RBP: ffff880031227b70 R08: 00000000ffffffff R09: 0000000000000020 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8800087edb40 R13: 0000000000000000 R14: ffff880000e0bcf0 R15: ffffffff8029c1ef FS: 00002b79280d26e0(0000) GS:ffffffff805d2100(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 Process xenwatch (pid: 69, threadinfo ffff88003e412000, task ffff88003e3ea080) Stack: 2e6b6361626b6c62 0000006364682e33 ffff880000000025 ffff8800087edb40 ffff880034383c00 ffff8800087edb40 ffff880034383c00 ffffffff8883f2eb 6669636570736e75 737361202c646569 Call Trace: [<ffffffff8883f2eb>] :blkbk:frontendchanged+0x21d/0x226 [<ffffffff803b9c78>] xenwatchthread+0x0/0x135 [<ffffffff803b90ca>] xenwatchhandlecallback+0x15/0x48 [<ffffffff803b9d94>] xenwatchthread+0x11c/0x135 [<ffffffff8029c407>] autoremovewakefunction+0x0/0x2e [<ffffffff8029c1ef>] keventdcreatekthread+0x0/0xc4 [<ffffffff80233be4>] kthread+0xfe/0x132 [<ffffffff80260b2c>] childrip+0xa/0x12 [<ffffffff8029c1ef>] keventdcreatekthread+0x0/0xc4 [<ffffffff80233ae6>] kthread+0x0/0x132 [<ffffffff80260b22>] childrip+0x0/0x12
Code: 48 8b b8 08 01 00 00 e8 b3 f6 a7 f7 85 c0 89 c6 74 0d 48 8b RIP [<ffffffff8883f03f>] :blkbk:updateblkifstatus+0x21f/0x2ae RSP <ffff88003e413df0> CR2: 0000000000000108 <0>Kernel panic - not syncing: Fatal exception (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
http://bugs.centos.org/bugviewadvancedpage.php?bugid=4517
Acknowledgements:
Red Hat would like to thank Vladymyr Denysov for reporting this issue.
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.
Problem description: Intel VT-d chipsets without interrupt remapping do not prevent a guest which owns a PCI device from using DMA to generate MSI interrupts by writing to the interrupt injection registers. This can be exploited to inject traps and gain control of the host.
References: http://lists.xensource.com/archives/html/xen-devel/2011-05/msg00687.html http://theinvisiblethings.blogspot.com/2011/05/following-white-rabbit-software-attacks.html http://www.invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf