Sometimes when trying to create new Xen domains, my Xen server will refuse to create the domain, complaining with “Error creating domain: Out of memory. xc_dom_boot_mem_init: can’t allocate low memory for domain”.

This problem is a currently known bug, there are various patches and work arounds being discussed on the Red Hat bug tracker. If you don’t want to rebuild Xen with a patch to try and resolve the issue I found that manually reducing the amount of memory that the host (Domain-0) was consuming would resolve the issue.

You can do this by running (as root):

$ xm mem-set Domain-0 1024M

Set to whatever memory value you want, if your host does nothing other than running Xen for all the VMs, you can set it quite low, I recommend 256MB.

This error only seems to happen on x86_64 servers, according to the bug report the reason was “For each vcpu of xen/ia64, it requires 16M contiguous memory for vhpt, but balloon driver didn’t consider this case when it balloons memory.”

For details, refer to bug 466021 at Red Hat.

A new 0-day attack on the Linux kernel has just been released by Brad Spengler called the “Chedder Bay Exploit” which exploits a flaw in the Linux 2.6.30+ kernel.

This exploit is interesting, in that the code doesn’t look particularly broken, but when compiled the compiler optimisations causes the compiled code to have a security hole.

For more technical details on this exploit and further news, check the LWN.net article or use the CVE reference CVE-2009-1897.

From my quick review of the exploit, it appears the attack uses Pulseaudio to bypass Selinux security if it is enabled and then performs an attack against the /dev/net/tun device, allowing a standard user to gain root access.

Not having pulseaudio or the tun kernel module loaded should prevent this exploit from working, although I have not yet had sufficient time to test this since I received the alert announcement around 3am NZ time.

The exploit affects the 2.6.30+ kernel releases and also some of the test kernel 2.6.18 kernel releases by Redhat.

However, all production kernel releases for RHEL/CentOS do not appear to be vulnerable since the change that introduced the security exploit had not been backported yet.

In my tests on CentOS 5.3 with kernel 2.6.18-128.1.16.el5xen on i386/xen, I was unable to trigger the exploit.

UPDATE 19th July 2009

I have a correction to make based on feedback from Brad Spengler, the exploit uses Pulseaudio if there is no SELinux present, or if it is in the disabled state.

However, if SELinux is enabled, the exploit uses a vulnerability in SELinux to gain privileges without the need of Pulseaudio – this is a situation where attempting to use SELinux to make yourself more secure actually leads to your system being less secure.

Many thanks to Brad for the explanation.