On 07/06/11 21:30, Patrick McHardy wrote:If the bug is easily triggered with your guest os, then you could try to capture the traffic with wireshark (or something else) in a configuration that doesn't crash your system. Save the traffic in a pcap file. Then you can see if resending that traffic in the vulnerable configuration triggers the bug (I don't know if something in Windows exists, but tcpreplay should work for Linux). Once you have such a capture , chances are the bug is even easily reproducible by us (unless it's hardware-specific). Success isn't guaranteed, but I think it's worth a shot...On 07.06.2011 05:33, Brad Campbell wrote:On 07/06/11 04:10, Bart De Schuymer wrote:Hi Brad,
This has probably nothing to do with ebtables, so please rmmod in case
it's loaded.
A few questions I didn't directly see an answer to in the threads I
scanned...
I'm assuming you actually use the bridging firewall functionality. So,
what iptables modules do you use? Can you reduce your iptables rules to
a core that triggers the bug?
Or does it get triggered even with an empty set of firewall rules?
Are you using a stock .35 kernel or is it patched?
Is this something I can trigger on a poor guy's laptop or does it
require specialized hardware (I'm catching up on qemu/kvm...)?
Not specialised hardware as such, I've just not been able to reproduce
it outside of this specific operating scenario.
The last similar problem we've had was related to the 32/64 bit compat
code. Are you running 32 bit userspace on a 64 bit kernel?
No, 32 bit Guest OS, but a completely 64 bit userspace on a 64 bit kernel.
Userspace is current Debian Stable. Kernel is Vanilla and qemu-kvm is current git