View Issue Details

IDProjectCategoryView StatusLast Update
0005636CentOS-5kvmpublic2012-05-26 17:04
ReporterMelhior Assigned To 
PrioritynormalSeveritycrashReproducibilityalways
Status newResolutionopen 
Product Version5.8 
Summary0005636: After start kvm guest (centos 5.8) - kernel panic host
DescriptionHost - Centos 5.8
Guest - Centos 5.8

eth0 -> br0

After update system (yum update)

Start Guest - 1-20 minute crash Host

downgrade kernel not resolved this problem

info.zip -
- dmidecode.txt
- images.xml
- Snapshot.gif - kernel panic screen
- rpm.txt - rpm -qa
- lsmod.txt
- dmesg.txt
- messages.txt


TagsNo tags attached.

Relationships

related to 0005638 newIssue Tracker CentOS-6 Kernel Panic on running KVM 

Activities

Melhior

Melhior

2012-03-30 19:39

reporter  

info.zip (42,514 bytes)
toracat

toracat

2012-03-30 21:55

manager   ~0014773

The messages.txt has these lines:

Mar 30 14:04:17 server1 kernel: ipt_hook: happy cracking.
Mar 30 14:04:20 server1 last message repeated 3 times
Mar 30 14:04:20 server1 kernel: Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
Mar 30 14:04:20 server1 kernel: [<0000000000000000>]
Mar 30 14:04:20 server1 kernel: PGD 12733f067 PUD 12733e067 PMD 0

A solution / workaround on the following page might work:

http://www.firewing1.com/node/606

"TL;DR: If you using CentOS 5 (or any other distro with an older kernel), use a DROP policy in your iptables configuration instead of REJECT!"
Melhior

Melhior

2012-04-02 05:42

reporter   ~0014776

works:

sysctl

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0

do not use REJECT in the FORWARD chain (default configuration centos) -D FORWARD RH-Firewall-1-INPUT


-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -j DROP
firewing1

firewing1

2012-05-03 15:59

reporter   ~0014986

I'm glad the blog post was able to helped someone, this bug was particularly frustrating to debug and find a fix for.

While using DROP is a quick fix/workaround for the problem, if the IRC users in #netfilter that I spoke to about this problem are correct then a better fix would be backport the patch from newer kernels that reconstructs packets from scratch when forwarding them to a VM instead of forwarding bad packets as-is (which, as I understand it, is what causes the kernel panic).
toracat

toracat

2012-05-03 16:20

manager   ~0014987

@firewing1

Do you happen to know where that patch is?
firewing1

firewing1

2012-05-03 16:25

reporter   ~0014988

No, sorry - the only information I have is based on my chats in #netfilter and they said that newer kernels reassemble packets when forwarding them. I don't know if that change is a small patch somewhere or a rewrite of a large part of the networking code in the kernel, so if we can't pinpoint it easily then we may as well just apply the DROP workaround.
toracat

toracat

2012-05-03 16:35

manager   ~0014989

OK, thanks. Thanks also for finding and offering the workaround.

Issue History

Date Modified Username Field Change
2012-03-30 19:39 Melhior New Issue
2012-03-30 19:39 Melhior File Added: info.zip
2012-03-30 21:55 toracat Note Added: 0014773
2012-04-02 05:42 Melhior Note Added: 0014776
2012-05-03 15:59 firewing1 Note Added: 0014986
2012-05-03 16:20 toracat Note Added: 0014987
2012-05-03 16:25 firewing1 Note Added: 0014988
2012-05-03 16:35 toracat Note Added: 0014989
2012-05-26 17:04 tigalch Relationship added related to 0005638