From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: David Miller <davem@davemloft.net>
Cc: michael.j.dilmore@gmail.com, 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:31:15 -0700 [thread overview]
Message-ID: <24539.1498084275@famine> (raw)
In-Reply-To: <20170621.175651.854625612625047729.davem@davemloft.net>
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
next prev parent reply other threads:[~2017-06-21 22:31 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
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 [this message]
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=24539.1498084275@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.