From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
To: 박수현 <suhyun.park@ahnlab.com>,
"Stephen Hemminger" <stephen@networkplumber.org>,
"David S. Miller" <davem@davemloft.net>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"bridge@lists.linux-foundation.org"
<bridge@lists.linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Bridge] [PATCH] bridge: missing null bridge device check causing null pointer dereference (bugfix)
Date: Thu, 06 Nov 2014 17:28:56 +0900 [thread overview]
Message-ID: <545B3148.8000704@lab.ntt.co.jp> (raw)
In-Reply-To: <8D1F1238A24CE743B8F3CED0F137C69E408AA087@EXMB02.ahnbang.ahnlab.com>
On 2014/11/06 16:58, 박수현 wrote:
>> -----Original Message-----
>> From: Toshiaki Makita [mailto:makita.toshiaki@lab.ntt.co.jp]
>> Sent: Thursday, November 06, 2014 4:07 PM
>> To: 박수현; Stephen Hemminger; David S. Miller
>> Cc: bridge@lists.linux-foundation.org; netdev@vger.kernel.org; linux-
>> kernel@vger.kernel.org
>> Subject: Re: [PATCH] bridge: missing null bridge device check causing null
>> pointer dereference (bugfix)
>>
>> On 2014/11/06 15:26, Su-Hyun Park wrote:
>>> the bridge device can be null if the bridge is being deleted while
>>> processing the packet, which causes the null pointer dereference in
>> switch statement.
>>
>> How can this happen??
>> It is guarded by rcu.
>> netdev_rx_handler_unregister() ensures rx_handler_data is non NULL.
>>
>
> The RCU protect rx_handler_data, not the bridge member port. It can be NULL according to below code.
>
> static inline struct net_bridge_port *br_port_get_rcu(const struct net_device *dev) {
> struct net_bridge_port *port = rcu_dereference(dev->rx_handler_data);
> return br_port_exists(dev) ? port : NULL;
> }
Seems to have been fixed for a year.
716ec052d228 ("bridge: fix NULL pointer deref of br_port_get_rcu")
Thanks,
Toshiaki Makita
WARNING: multiple messages have this Message-ID (diff)
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
To: 박수현 <suhyun.park@ahnlab.com>,
"Stephen Hemminger" <stephen@networkplumber.org>,
"David S. Miller" <davem@davemloft.net>
Cc: "bridge@lists.linux-foundation.org"
<bridge@lists.linux-foundation.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] bridge: missing null bridge device check causing null pointer dereference (bugfix)
Date: Thu, 06 Nov 2014 17:28:56 +0900 [thread overview]
Message-ID: <545B3148.8000704@lab.ntt.co.jp> (raw)
In-Reply-To: <8D1F1238A24CE743B8F3CED0F137C69E408AA087@EXMB02.ahnbang.ahnlab.com>
On 2014/11/06 16:58, 박수현 wrote:
>> -----Original Message-----
>> From: Toshiaki Makita [mailto:makita.toshiaki@lab.ntt.co.jp]
>> Sent: Thursday, November 06, 2014 4:07 PM
>> To: 박수현; Stephen Hemminger; David S. Miller
>> Cc: bridge@lists.linux-foundation.org; netdev@vger.kernel.org; linux-
>> kernel@vger.kernel.org
>> Subject: Re: [PATCH] bridge: missing null bridge device check causing null
>> pointer dereference (bugfix)
>>
>> On 2014/11/06 15:26, Su-Hyun Park wrote:
>>> the bridge device can be null if the bridge is being deleted while
>>> processing the packet, which causes the null pointer dereference in
>> switch statement.
>>
>> How can this happen??
>> It is guarded by rcu.
>> netdev_rx_handler_unregister() ensures rx_handler_data is non NULL.
>>
>
> The RCU protect rx_handler_data, not the bridge member port. It can be NULL according to below code.
>
> static inline struct net_bridge_port *br_port_get_rcu(const struct net_device *dev) {
> struct net_bridge_port *port = rcu_dereference(dev->rx_handler_data);
> return br_port_exists(dev) ? port : NULL;
> }
Seems to have been fixed for a year.
716ec052d228 ("bridge: fix NULL pointer deref of br_port_get_rcu")
Thanks,
Toshiaki Makita
WARNING: multiple messages have this Message-ID (diff)
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
To: 박수현 <suhyun.park@ahnlab.com>,
"Stephen Hemminger" <stephen@networkplumber.org>,
"David S. Miller" <davem@davemloft.net>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"bridge@lists.linux-foundation.org"
<bridge@lists.linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] bridge: missing null bridge device check causing null pointer dereference (bugfix)
Date: Thu, 06 Nov 2014 17:28:56 +0900 [thread overview]
Message-ID: <545B3148.8000704@lab.ntt.co.jp> (raw)
In-Reply-To: <8D1F1238A24CE743B8F3CED0F137C69E408AA087@EXMB02.ahnbang.ahnlab.com>
On 2014/11/06 16:58, 박수현 wrote:
>> -----Original Message-----
>> From: Toshiaki Makita [mailto:makita.toshiaki@lab.ntt.co.jp]
>> Sent: Thursday, November 06, 2014 4:07 PM
>> To: 박수현; Stephen Hemminger; David S. Miller
>> Cc: bridge@lists.linux-foundation.org; netdev@vger.kernel.org; linux-
>> kernel@vger.kernel.org
>> Subject: Re: [PATCH] bridge: missing null bridge device check causing null
>> pointer dereference (bugfix)
>>
>> On 2014/11/06 15:26, Su-Hyun Park wrote:
>>> the bridge device can be null if the bridge is being deleted while
>>> processing the packet, which causes the null pointer dereference in
>> switch statement.
>>
>> How can this happen??
>> It is guarded by rcu.
>> netdev_rx_handler_unregister() ensures rx_handler_data is non NULL.
>>
>
> The RCU protect rx_handler_data, not the bridge member port. It can be NULL according to below code.
>
> static inline struct net_bridge_port *br_port_get_rcu(const struct net_device *dev) {
> struct net_bridge_port *port = rcu_dereference(dev->rx_handler_data);
> return br_port_exists(dev) ? port : NULL;
> }
Seems to have been fixed for a year.
716ec052d228 ("bridge: fix NULL pointer deref of br_port_get_rcu")
Thanks,
Toshiaki Makita
next prev parent reply other threads:[~2014-11-06 8:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-06 6:26 [PATCH] bridge: missing null bridge device check causing null pointer dereference (bugfix) Su-Hyun Park
2014-11-06 6:33 ` [Bridge] " Su-Hyun Park
2014-11-06 7:07 ` Toshiaki Makita
2014-11-06 7:07 ` Toshiaki Makita
2014-11-06 7:07 ` Toshiaki Makita
2014-11-06 7:58 ` 박수현
2014-11-06 7:58 ` [Bridge] " 박수현
2014-11-06 7:58 ` 박수현
2014-11-06 8:28 ` Toshiaki Makita [this message]
2014-11-06 8:28 ` Toshiaki Makita
2014-11-06 8:28 ` Toshiaki Makita
2014-11-06 11:35 ` [Bridge] " Eric Dumazet
2014-11-06 11:35 ` Eric Dumazet
2014-11-06 11:35 ` Eric Dumazet
2014-11-06 11:52 ` 박수현
2014-11-06 11:52 ` [Bridge] " 박수현
2014-11-06 11:52 ` 박수현
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=545B3148.8000704@lab.ntt.co.jp \
--to=makita.toshiaki@lab.ntt.co.jp \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=suhyun.park@ahnlab.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.