On 21/06/17 23:39, Jay Vosburgh wrote:
Michael J Dilmore <michael.j.dilm...@gmail.com> wrote:
On 21/06/17 22:56, David Miller wrote:
From: Michael D <michael.j.dilm...@gmail.com>
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
away?
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");
return ERROR_CODE
}
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.
-J
---
-Jay Vosburgh, jay.vosbu...@canonical.com
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?
