netdev - Re: Kernel panic when using bridge

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]

Message-ID: <4DA39330.2030102@scotdoyle.com>
Date:	Mon, 11 Apr 2011 18:48:00 -0500
From:	Scot Doyle <lkml@...tdoyle.com>
To:	Hiroaki SHIMODA <shimoda.hiroaki@...il.com>,
	Stephen Hemminger <shemminger@...tta.com>
CC:	netdev@...r.kernel.org,
	Sebastian Nickel <Sebastian.Nickel@...zner.de>,
	Pallai Roland <pallair@...ex.hu>
Subject: Re: Kernel panic when using bridge

On 04/09/2011 02:19 AM, Hiroaki SHIMODA wrote:
>
> It seems that the bug trap is occurred in ip_options_compile() due to
> rt is NULL.
>
> 	8b 96 cc 00 00 00       mov    0xcc(%rsi),%edx
> rsi is rt, and 0xcc means rt->rt_spec_dst. So I think below code hit
> the bug trap.
>
> 332	if (skb) {
> 333		memcpy(&optptr[optptr[2]-1],&rt->rt_spec_dst, 4);<- here
> 334		opt->is_changed = 1;
> 335	}
>
> And call trace seems as follows.
>    __netif_receive_skb()
>      ->  br_handle_frame()
>           ->  NF_HOOK()
>                ->  br_nf_pre_routing()
>                     ->  br_parse_ip_options()
>                          ->  ip_options_compile()
>
> br_parse_ip_options() was introduced at 462fb2a (bridge : Sanitize
> skb before it enters the IP stack) but ip_options_compile() or
> ip_options_rcv_srr() seems to be called with no rt info.

Thanks to a tip from Sebastian, I can now reproduce this panic by 
running "IP Stack Integrity Checker v0.07" from another machine on the 
same subnet with command "icmpsic -s x.y.z.a -d x.y.z.b" where "x.y.z.a" 
is IP address of the other machine and "x.y.z.b" is the IP address of 
the target. When I enable iptables logging on the target machine, no 
panic occurs. When I disable iptables logging (but otherwise leave the 
same iptables rules) a panic occurs within a few seconds.

Thanks Hiroaki for the analysis of the kernel panic output. I've 
confirmed that you are correct by placing a printk just before those two 
lines. In every panic, the printk was triggered on line 333 of 
net/ipv4/ip_options.c

The kernel panic does not occur after applying the following patch.

# diff net/ipv4/ip_options.c.original net/ipv4/ip_options.c.fix
332c332
<                 if (skb) {
---
 >                 if (skb && rt) {
374c374
<                     if (skb) {
---
 >                     if (skb && rt) {

What do you all think? Will it cause other problems?
--
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