netdev - Re: [RFC PATCH] bridge: netfilter: fix skb->nf_bridge NULL panic in br_nf_forward

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:	Fri, 6 Jul 2012 23:37:50 +0800
From:	Lin Ming <mlin@...pku.edu.cn>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Massimo Cetra <ctrix+debianbugs@...ynet.it>,
	netdev@...r.kernel.org, Stephen Hemminger <shemminger@...tta.com>,
	"David S. Miller" <davem@...emloft.net>,
	Julian Anastasov <ja@....bg>
Subject: Re: [RFC PATCH] bridge: netfilter: fix skb->nf_bridge NULL panic in br_nf_forward_finish

On Fri, Jul 6, 2012 at 11:06 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Fri, 2012-07-06 at 22:19 +0800, Lin Ming wrote:
>> I can reproduce similiar panic with 3.5-rc5 kernel as Massimo reported at:
>> http://marc.info/?l=linux-netdev&m=134089242113979&w=2
>>
>> The steps to reproduce as follow,
>>
>> 1. On Host1, setup brige br0(192.168.1.106)
>> 2. Boot a kvm guest(192.168.1.105) on Host1 and start httpd
>> 3. Start IPVS service on Host1
>>    ipvsadm -A -t 192.168.1.106:80 -s rr
>>    ipvsadm -a -t 192.168.1.106:80 -r 192.168.1.105:80 -m
>> 4. Run apache benchmark on Host2(192.168.1.101)
>>    ab -n 1000 http://192.168.1.106/
>>
>> The panic happened in br_nf_forward_finish because skb->nf_bridge is NULL.
>> skb->nf_bridge is set to NULL in ip_vs_reply4 hook.
>>
>> br_nf_forward_ip():
>>   NF_HOOK(pf, NF_INET_FORWARD, skb, brnf_get_logical_dev(skb, in), parent,
>>                 br_nf_forward_finish);
>>
>> This calls IPVS hook ip_vs_reply4.
>>
>> ip_vs_reply4
>>   ip_vs_out
>>     handle_response
>>       ip_vs_notrack
>>         nf_reset()
>>         {
>>           skb->nf_bridge = NULL;
>>         }
>>
>> This patch added skb->nf_bridge check in br_nf_forward_finish and the panic gone.
>> But I am really not sure if this is the right fix.
>> Please help to review.
>>
>> The panic log attached.
> ...
>> Signed-off-by: Lin Ming <mlin@...pku.edu.cn>
>> ---
>>  net/bridge/br_netfilter.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
>> index e41456b..10da415 100644
>> --- a/net/bridge/br_netfilter.c
>> +++ b/net/bridge/br_netfilter.c
>> @@ -719,7 +719,7 @@ static int br_nf_forward_finish(struct sk_buff *skb)
>>       struct nf_bridge_info *nf_bridge = skb->nf_bridge;
>>       struct net_device *in;
>>
>> -     if (!IS_ARP(skb) && !IS_VLAN_ARP(skb)) {
>> +     if (!IS_ARP(skb) && !IS_VLAN_ARP(skb) && nf_bridge) {
>>               in = nf_bridge->physindev;
>>               if (nf_bridge->mask & BRNF_PKT_TYPE) {
>>                       skb->pkt_type = PACKET_OTHERHOST;
>
> So after your patch we have the code in the else clause :
>
> } else {
>         in = *((struct net_device **)(skb->cb));
> }
>
> But do we really have a "struct net_device" pointer stored in skb->cb[]
> at this stage ?
>
> AFAIK this is set only for ARP_FORWARD (br_nf_forward_arp() line 838 :
> *d = (struct net_device *)in;),
> not in br_nf_forward_ip()
>
> If we have garbage instead, we can have other bugs later...

You are right.

The fundamental problem maybe in IPVS hook ip_vs_reply4 ......
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html