# Kernel panic: gentoo hardened + grsecurity + ICMPV6 = bad

## Cheesepie

Hi all,

having a problem with gentoo hardened.

I have a box running that serves as a local SMB / DHCP / router / firewall for a small company.  I just upgraded it to 2.6.14-hardened-r8 and am having some problems.

The kernel has both pax and grsecurity enabled. Grsecurity is set to security level "high" and unmodified (except for I have also disabled priviledged I/O and restricted /proc/ to user only). 

The local network interface (IE, the interface connected to the LAN) is a bridged connection (IE, 2 cards form 1 br0 interface) of 2 broadcom NICs running tg3 (the version is the default included with 2.6.14-hardened, too lazy to look it up). The NICs are a 5751 based PCIE card and a 5702 based PCI card.

The box is not running nor configured for ipv6. It does not have the ipv6 modules installed (nor compiled into the kernel), and thus it does not have ipv6 configured in iptables, apache, or anything else.

On the same network is another box. It is an ubuntu laptop with ipv6 installed. If this laptop has been in use on another, ipv6 capable but primarily ipv4 network (and is thus configured for use on this other network- ip info, routing info, arp info, etc), connecting it to my network and running dhclient will result in a kernel panic on the server. 

I have reproduced this, monitoring it with ethereal, and found that dhcpd is not at fault for this error. 

According to ethereal, it would seem that anytime the server machine receives an "ICMPV6 Router Solicitation" from the laptop (in normal use, this comes as a result of running dhclient), it crashes. It crashes even when I have killed all running dhcpd processes. 

In short

gentoo hardened without ipv6 + grsecurity + icmpv6 router solicitation = PANIC

the icmpv6 router solicitation is, in my case, being generated by running dhclient. But being caused by dhclient does not seem to be a requirement for a panic.

Not sure where to turn for help with this  :Sad: 

edit: further research has indicated that broadcom's tg3 driver in combination with ethernet bridging may play a part in this. I will do some investigation (IE, remove the bridge) and post results in a bit.

----------

## Cheesepie

SOLVED

The problem is due to a bug in broadcom's tg3 driver's inability to work properly with bridged interfaces.

I'm not sure what affect grsecurity had on the whole scenario, but by removing bridging from the mix alltogether, the problem magically went away. 

Swapping out the nics with similiar intel ones, I put those intel nics into a bridge and tested it. The kernel panic did not appear with bridged intel nics. 

So, apparently, it goes like this

Broadcom's tg3 driver included in 2.6.14-hardened-r8 + bridged 5702 / 5751 + bridge interface receiving an ICMPV6 Router Solicitation ( + grsecurity ) = PANIC

Also make note that the 5751 is using MSI interrupts. I know the tg3 driver had problems with these in the past, perhaps it is related. 

I put grsecurity in parenthesis because I was not able to norrow down whether or not grsecurity has any affect on the situation. 

edit: my solution was to remove the ethernet bridge alltogether. Since the box runs iptables, I can just use that to route as necessary. 

I just forwarded this post to the folks at broadcom pqa. hopefully they will take a look at it. 

darned bug just took me 4 hours to track down  :Neutral: 

----------

## fcgreg

 *Cheesepie wrote:*   

> ... The problem is due to a bug in broadcom's tg3 driver's inability to work properly with bridged interfaces.
> 
> I'm not sure what affect grsecurity had on the whole scenario, but by removing bridging from the mix alltogether, the problem magically went away.

 

Are you sure that it was the Broadcom driver?  I am having the exact kernel panic on one of our servers (the only one running that kernel - hardened-sources-2.6.14-r8).  I just upgraded its kernel and system libs this week and now I'm having panics within 2-16 hours of uptime.

I am not able to determine exactly what triggers the panic and the call stack is very long -- only the tail end of it remains on the console.  However, it contains many lines about the bridged network interfaces as well as lines about interrupts and the kernel.  Then it panics with this:

```
[<c014a1ec7>]L6+0x0/0x2

CODE: Bad EIP value

<0>Kernel Panic - Not Syncing:  Fatal Exception In Interrupt
```

The NIC's are Intel PRO/1000 (e1000) cards (on-board so I cannot swap them out).  I have GRSecurity enabled at "LOW" with no other security options changed / enabled. I use this machine for a bridged VPN solution, therefore the network bridging options are on (802.11d) and the TUN/TAP virtual interface is enabled.  I do NOT have IPV6 enabled.

This machine is also used to store a few network shares for Windows users, therefore Samba is installed.

The closest I can get to reproducing this is that the problem seems to happen more often when Windows systems are connecting to the Samba shares.  However, it doesn't happen right away and is not at all consistent.  This one has been very hard to chase down.

Prior to the upgrade it had been running fine for months in the same configuration exactly as mentioned above.  Any thoughts?

----------

## fcgreg

FYI:  I've found an exact bug reference in Bugzilla for this issue.  It is confirmed as being caused by network bridging support with a certain (bad) patch in the kernel, and probably related to IPV6 network packets.

In case this helps someone else...

Hopefully a fixed kernel release for hardened will be out shortly.

----------

