Messages in this thread | | David Miller <davem@davemloft.net> wrote:
>From: Michael D <michael.j.dilmore@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.
Looking at the code more carefully than I did earlier, the only way the BUG_ON will hit is if the rx_handler_data is NULL for a bonding slave when this code executes.
This should be impossible, as there doesn't appear to be any way to get into bond_option_active_slave_set for a slave prior to bond_enslave registering the rx_handler for that slave, as these operations are mutexed by RTNL.
-J
--- -Jay Vosburgh, jay.vosburgh@canonical.com
| |