linux-kernel - Re: BUG: unable to handle kernel NULL pointer dereference in ipv6_select

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 22 Dec 2011 18:41:32 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Chris Boot <bootc@...tc.net>
Cc:	David Miller <davem@...emloft.net>,
	lkml <linux-kernel@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>,
	Steffen Klassert <steffen.klassert@...unet.com>
Subject: Re: BUG: unable to handle kernel NULL pointer dereference in
 ipv6_select_ident

Le jeudi 22 décembre 2011 à 15:54 +0000, Chris Boot a écrit :

> Eric,
> 
> I'm seeing a new problem now with IPv6 on my bridge, I don't know if 
> it's related to any of the patches you gave me.
> 
> Basically, I have eth0 and eth1 in a balance-rr bond (bond0), and this 
> is added as a port in a bridge. When the bond and bridge are freshly 
> brought up, IPv4 works fine but it appears to be deaf to IPv6 traffic. 
> It stays this way until I run 'tcpdump -i eth0' and 'tcpdump -i eth1'. 
> If I run tcpdump with the -p flag to not enable promiscuous mode, the 
> interfaces remain deaf. Only if they enter promiscuous mode do they 
> start to listen to each other. It also doesn't help to run tcpdump 
> against bond0 or br0 at all.
> 
> I'm not sure if once I've killed tcpdump they become deaf again, but I 
> have enough IPv6 traffic to keep the neighbour entry alive.

Thats probably a separate issue. It would be better to open a new thread
on netdev, instead of continuing this one.

IPv6 needs multicast capabilities, so maybe balance-rr bonding mode is
not propagating multicat filters properly on both nics.

It might be a problem on one of your NIC.

(tcpdump automatically installs promiscous mode, so all multicast frames
are received, regardless of previous multicast filters in place)




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/