From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: Michael J Dilmore <michael.j.dilmore@gmail.com>
Cc: David Miller <davem@davemloft.net>,
vfalico@gmail.com, andy@greyhouse.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, joe@perches.com
Subject: Re: [PATCH] Convert BUG_ON to WARN_ON in bond_options.c
Date: Wed, 21 Jun 2017 15:39:28 -0700 [thread overview]
Message-ID: <24691.1498084768@famine> (raw)
In-Reply-To: <125b4ae9-2cb7-3532-5391-24404cf6eaec@gmail.com>
Michael J Dilmore <michael.j.dilmore@gmail.com> wrote:
>On 21/06/17 22:56, David Miller 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.
>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.vosburgh@canonical.com
next prev parent reply other threads:[~2017-06-21 22:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-21 18:02 [PATCH] Convert BUG_ON to WARN_ON in bond_options.c Michael J Dilmore
2017-06-21 18:33 ` Jay Vosburgh
2017-06-21 21:35 ` Michael D
2017-06-21 21:36 ` David Miller
2017-06-21 21:41 ` Michael D
2017-06-21 21:56 ` David Miller
2017-06-21 22:27 ` Michael J Dilmore
2017-06-21 22:39 ` Jay Vosburgh [this message]
2017-06-21 23:04 ` Michael J Dilmore
2017-06-22 8:04 ` Michal Kubecek
2017-06-22 8:14 ` Bjørn Mork
2017-06-21 22:31 ` Jay Vosburgh
2017-06-21 21:57 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=24691.1498084768@famine \
--to=jay.vosburgh@canonical.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.j.dilmore@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=vfalico@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.