Note too that if I start the libvirt virtual network after starting my other dnsmasq server that it doesn't end up listening on localhost.

Huh, I was hitting this too but didn't realize it was libvirt related.

I verified that adding '--except-interface lo' to the new 0.10.2.2 dnsmasq command line generates similar lsof output to 0.10.2.1 dnsmasq command line (basically what Jeff reported above, but without the 127.0.0.1 and [::1] bits)

The easiest way to have network manager run dnsmasq is adding 'dns=dnsmasq' to /etc/NetworkManager/NetworkManager.conf and logout/login

Laine, thoughts?

Yeah, in fact:

       -i, --interface=<interface name>
              Listen only on the specified interface(s). Dnsmasq automatically
              adds the loopback (local) interface to the list of interfaces to
              use  when  the --interface option  is used. If no --interface or
              --listen-address options are given dnsmasq listens on all avail‐
              able  interfaces except any given in --except-interface options.
              IP alias interfaces (eg "eth1:0") cannot be used  with  --inter‐
              face   or   --except-interface   options,  use  --listen-address
              instead.

...so if you don't include --except-interface=lo then it will the loopback automatically. Seems like a mis-feature to me, but whatever... ;)

My recollection is that when I tried only switching --listen-address= to --interface=, the problem described in CVE 2012-3411 (Bug 833033) remained, but went away when I also removed --except-interface=lo. Something else could have been happening, so I'll double check tonight.

Bah.

I apparently was lacking sleep when I tested, and gave too much credence to the suggestion in https://bugzilla.redhat.com/show_bug.cgi?id=833033#c36 . The bit that didn't get rid of the problem described in the CVE was adding --interface without removing --listen-address; leaving in --except-interface has no ill effects wrt. the CVE.

I'm creating patches now for all the affected branches.

Sorry for the inconvenience :-(

BTW, I've just discovered that if the non-libvirt dnsmasq instance uses "bind-dynamic" instead of "bind-interfaces", it will be able to start; likewise if the non-libvirt dnsmasq is already running when libvirt starts its networks (even with "bind-interfaces" instead of "bind-dynamic" (I didn't check which dnsmasq actually receives the DNS requests sent to 127.0.0.1, since the answer will anyway be "the *wrong* one" in at least one of those cases)

Fix posted upstream. Waiting for ACK:

https://www.redhat.com/archives/libvir-list/2012-December/msg00767.html

I did test that it both fixed this new problem, and didn't un-fix the CVE. I also posted a backport to the v0.10.2-maint branch, since the code being fixed is all changed since then, so a cherry-pick wouldn't suffice.

I don't know if it's any longer possible to get anything into F18, so this may have to be a 0-day update.

libvirt-0.10.2.2-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libvirt-0.10.2.2-2.fc18

libvirt-0.10.2.2-3.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libvirt-0.10.2.2-3.fc18

Stuff can still go into F18 but there needs to be a justification as to why it needs to go into the frozen package set and media rather than going out as a 0-day. If you want that, the mechanism is to mark the bug as blocking the bug 'F18-accepted' and add a comment to explain why we should break freeze for this bug. See https://fedoraproject.org/wiki/QA:SOP_nth_bug_process . thanks.

Note that https://bugzilla.redhat.com/show_bug.cgi?id=882309 is already acceptednth so we could fudge a bit and say we should take the newest libvirt to fix that, rather than just taking the build which fixed that but also introduced this regression.

sigh - and just to complicate things a bit more, we don't want to pull a new libvirt unless it also fixes https://bugzilla.redhat.com/show_bug.cgi?id=884957 , which was identified as another regression introduced by the fix for 882309.

(In reply to comment #12)
> sigh - and just to complicate things a bit more, we don't want to pull a new
> libvirt unless it also fixes
> https://bugzilla.redhat.com/show_bug.cgi?id=884957 , which was identified as
> another regression introduced by the fix for 882309.

No, bug 884957 does NOT affect Fedora.  It was a mis-type on my part when I was mentioning that the fix for bug 882309 introduced THIS bug as a regression.

ah, OK. that simplifies things a bit. i think we can just say 'we'll pull 0.10.2.2-3 as the fix for 882309 so it doesn't regress anything'.

libvirt-0.10.2.2-3.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.