netdev - Re: kernel BUG in ipmr_queue

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, 30 Oct 2015 10:47:36 -0700
From:	Ani Sinha <ani@...sta.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Florian Westphal <fw@...len.de>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Ani Sinha <ani@...rban.org>, fruggeri <fruggeri@...sta.com>
Subject: Re: kernel BUG in ipmr_queue_xmit()

On Fri, Oct 30, 2015 at 4:00 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Fri, 2015-10-30 at 11:48 +0100, Florian Westphal wrote:
>> Hannes Frederic Sowa <hannes@...essinduktion.org> wrote:
>> > > > > @@ -936,7 +936,9 @@ static void ipmr_cache_resolve(struct net *net, struct mr_table *mrt,
>> > > > >
>> > > > >                       rtnl_unicast(skb, net, NETLINK_CB(skb).portid);
>> > > > >               } else {
>> > > > > +                     preempt_disable();
>> > > > >                       ip_mr_forward(net, mrt, skb, c, 0);
>> > > > > +                     preempt_enable();
>> > > > >               }
>> > > > >       }
>> > > > >  }
>> > > >
>> > > > I do not believe this fix is correct.
>> > >
>> > > Yes, sorry.  I should have suggested local_bh_disable instead.
>> > >
>> > > > Better replace the
>> > > > IP_INC_STATS_BH() by IP_INC_STATS()
>> > > >
>> > > > and IP_ADD_STATS_BH() by IP_ADD_STATS()
>> > >
>> > > Hmm, whats the rationale for this?
>> > >
>> > > Note that IP_ADD_STATS_BH in question is unconditional (not in
>> > > error path).  It seems that its virtually always called from softirq
>> > > except in the setsockopt case.
>> >
>> > The naming of the functions is bad if you compare them to e.g.
>> > spin_lock_bh.
>> >
>> > STATS_BH can only be used from bottom half and the normal ones (without
>> > _BH) can be called from everywhere. It is a common pattern in the
>> > kernel.
>> >
>> > Eric's proposal is correct.
>>
>> Yes, its correct but it results in 4 additonal bh on/off calls
>> for the common case, hence my question.
>>
>> Moving the one ip_mr_forward into bh-off keeps the bh-disable thing
>> in the setsockopt path.
>
> I have no idea how long is the ip_mr_forward(net, mrt, skb, c, 0)
> section, and if GFP_KERNEL allocations were attempted in this path.
>
> The proposed fix might add other regressions.
>
> I do not want to spend time auditing this code that nobody uses.
>
> While on x86, IP_INC_STATS() does not use additional bh on/off calls
>

for 32 bit archs, it does in SNMP_ADD_STATS64_USER()


> In general, we should disable interrupts (even if soft) for limited
> amount of times.
>
>
--
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