Re: [PATCH] Convert BUG_ON to WARN_ON in bond_options.c

From: Michael J Dilmore
Date: Wed Jun 21 2017 - 19:05:07 EST

On 21/06/17 23:39, Jay Vosburgh wrote:
Michael J Dilmore <michael.j.dilmore@xxxxxxxxx> wrote:

On 21/06/17 22:56, David Miller wrote:

From: Michael D <michael.j.dilmore@xxxxxxxxx>
Date: Wed, 21 Jun 2017 22:41:07 +0100

I don't think you can stop it being dereferenced... you just need to
prevent an attacker from exploiting the null pointer dereference
vulnerability right? And this is done by returning the function right
What's all of this about an "attacker"?

If there is a bug, we dererence a NULL pointer, and we should
fix that bug.

The BUG_ON() helps us see where the problem is while at the
same time stopping the kernel before the NULL deref happens.
Ok this is starting to make sense now - went a bit off track but think my
general thinking is ok - i.e. if we return the function with an error code
before the dereference then this basically does the same thing as BUG_ON
but without crashing the kernel.

Something like:

if (WARN_ON(!new_active_slave) {
netdev_dbg("Can't add new active slave - pointer null");
In general, yes, but in this case, the condition should be
impossible to hit, so BUG_ON seems appropriate.

If bond_slave_get_rtnl/rcu() returns NULL for an actual bonding
slave, other code paths (bond_fill_slave_info, bond_handle_frame) will
likely crash before getting to this one.


-Jay Vosburgh, jay.vosburgh@xxxxxxxxxxxxx
That did cross my mind but I read that Linus that was quite averse to BUG_ON anywhere in the kernel so thought it might be have been worth doing.

Is it worth at least wrapping BUG_ON in an unlikely macro then?