All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()
@ 2018-06-21 20:14 ` Garry McNulty
  0 siblings, 0 replies; 12+ messages in thread
From: Garry McNulty @ 2018-06-21 20:14 UTC (permalink / raw)
  To: netdev; +Cc: stephen, davem, jiri, nikolay, bridge, linux-kernel, Garry McNulty

br_port_get_rtnl() can return NULL if the network device is not a bridge
port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and
br_port_fill_slave_info() callbacks dereference this pointer without
checking. Currently this is not a problem because slave devices always
set this flag. Add null check in case these conditions ever change.

Detected by CoverityScan, CID 1339613 ("Dereference null return value")

Signed-off-by: Garry McNulty <garrmcnu@gmail.com>
---
 net/bridge/br_netlink.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 9f5eb05b0373..b3ad135b7157 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -947,13 +947,14 @@ static int br_port_slave_changelink(struct net_device *brdev,
 				    struct netlink_ext_ack *extack)
 {
 	struct net_bridge *br = netdev_priv(brdev);
+	struct net_bridge_port *p = br_port_get_rtnl(dev);
 	int ret;
 
-	if (!data)
+	if (!data || !p)
 		return 0;
 
 	spin_lock_bh(&br->lock);
-	ret = br_setport(br_port_get_rtnl(dev), data);
+	ret = br_setport(p, data);
 	spin_unlock_bh(&br->lock);
 
 	return ret;
@@ -963,7 +964,9 @@ static int br_port_fill_slave_info(struct sk_buff *skb,
 				   const struct net_device *brdev,
 				   const struct net_device *dev)
 {
-	return br_port_fill_attrs(skb, br_port_get_rtnl(dev));
+	struct net_bridge_port *p = br_port_get_rtnl(dev);
+
+	return p ? br_port_fill_attrs(skb, p) : -EINVAL;
 }
 
 static size_t br_port_get_slave_size(const struct net_device *brdev,
-- 
2.14.4


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* [Bridge] [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()
@ 2018-06-21 20:14 ` Garry McNulty
  0 siblings, 0 replies; 12+ messages in thread
From: Garry McNulty @ 2018-06-21 20:14 UTC (permalink / raw)
  To: netdev; +Cc: jiri, nikolay, bridge, linux-kernel, Garry McNulty, davem

br_port_get_rtnl() can return NULL if the network device is not a bridge
port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and
br_port_fill_slave_info() callbacks dereference this pointer without
checking. Currently this is not a problem because slave devices always
set this flag. Add null check in case these conditions ever change.

Detected by CoverityScan, CID 1339613 ("Dereference null return value")

Signed-off-by: Garry McNulty <garrmcnu@gmail.com>
---
 net/bridge/br_netlink.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 9f5eb05b0373..b3ad135b7157 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -947,13 +947,14 @@ static int br_port_slave_changelink(struct net_device *brdev,
 				    struct netlink_ext_ack *extack)
 {
 	struct net_bridge *br = netdev_priv(brdev);
+	struct net_bridge_port *p = br_port_get_rtnl(dev);
 	int ret;
 
-	if (!data)
+	if (!data || !p)
 		return 0;
 
 	spin_lock_bh(&br->lock);
-	ret = br_setport(br_port_get_rtnl(dev), data);
+	ret = br_setport(p, data);
 	spin_unlock_bh(&br->lock);
 
 	return ret;
@@ -963,7 +964,9 @@ static int br_port_fill_slave_info(struct sk_buff *skb,
 				   const struct net_device *brdev,
 				   const struct net_device *dev)
 {
-	return br_port_fill_attrs(skb, br_port_get_rtnl(dev));
+	struct net_bridge_port *p = br_port_get_rtnl(dev);
+
+	return p ? br_port_fill_attrs(skb, p) : -EINVAL;
 }
 
 static size_t br_port_get_slave_size(const struct net_device *brdev,
-- 
2.14.4


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()
  2018-06-21 20:14 ` [Bridge] " Garry McNulty
@ 2018-06-21 22:20   ` David Miller
  -1 siblings, 0 replies; 12+ messages in thread
From: David Miller @ 2018-06-21 22:20 UTC (permalink / raw)
  To: garrmcnu; +Cc: netdev, stephen, jiri, nikolay, bridge, linux-kernel

From: Garry McNulty <garrmcnu@gmail.com>
Date: Thu, 21 Jun 2018 21:14:27 +0100

> br_port_get_rtnl() can return NULL if the network device is not a bridge
> port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and
> br_port_fill_slave_info() callbacks dereference this pointer without
> checking. Currently this is not a problem because slave devices always
> set this flag. Add null check in case these conditions ever change.
> 
> Detected by CoverityScan, CID 1339613 ("Dereference null return value")
> 
> Signed-off-by: Garry McNulty <garrmcnu@gmail.com>

I don't think this is reasonable.

The bridge code will never, ever, install a slave that doesn't have
that bit set.  It's the most fundamental aspect of how these objects
are managed.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bridge] [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()
@ 2018-06-21 22:20   ` David Miller
  0 siblings, 0 replies; 12+ messages in thread
From: David Miller @ 2018-06-21 22:20 UTC (permalink / raw)
  To: garrmcnu; +Cc: jiri, nikolay, netdev, bridge, linux-kernel

From: Garry McNulty <garrmcnu@gmail.com>
Date: Thu, 21 Jun 2018 21:14:27 +0100

> br_port_get_rtnl() can return NULL if the network device is not a bridge
> port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and
> br_port_fill_slave_info() callbacks dereference this pointer without
> checking. Currently this is not a problem because slave devices always
> set this flag. Add null check in case these conditions ever change.
> 
> Detected by CoverityScan, CID 1339613 ("Dereference null return value")
> 
> Signed-off-by: Garry McNulty <garrmcnu@gmail.com>

I don't think this is reasonable.

The bridge code will never, ever, install a slave that doesn't have
that bit set.  It's the most fundamental aspect of how these objects
are managed.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()
  2018-06-21 22:20   ` [Bridge] " David Miller
  (?)
@ 2018-06-21 23:21     ` Stephen Hemminger
  -1 siblings, 0 replies; 12+ messages in thread
From: Stephen Hemminger @ 2018-06-21 23:21 UTC (permalink / raw)
  To: David Miller; +Cc: garrmcnu, netdev, jiri, nikolay, bridge, linux-kernel

On Fri, 22 Jun 2018 07:20:56 +0900 (KST)
David Miller <davem@davemloft.net> wrote:

> From: Garry McNulty <garrmcnu@gmail.com>
> Date: Thu, 21 Jun 2018 21:14:27 +0100
> 
> > br_port_get_rtnl() can return NULL if the network device is not a bridge
> > port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and
> > br_port_fill_slave_info() callbacks dereference this pointer without
> > checking. Currently this is not a problem because slave devices always
> > set this flag. Add null check in case these conditions ever change.
> > 
> > Detected by CoverityScan, CID 1339613 ("Dereference null return value")
> > 
> > Signed-off-by: Garry McNulty <garrmcnu@gmail.com>  
> 
> I don't think this is reasonable.
> 
> The bridge code will never, ever, install a slave that doesn't have
> that bit set.  It's the most fundamental aspect of how these objects
> are managed.

Agree with dave. Workarounds for static tools are ok if they don't introduce
other paths. But if your fix introduces another error path which can never
be reached, it is hurting not helping.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()
@ 2018-06-21 23:21     ` Stephen Hemminger
  0 siblings, 0 replies; 12+ messages in thread
From: Stephen Hemminger @ 2018-06-21 23:21 UTC (permalink / raw)
  To: David Miller; +Cc: jiri, nikolay, netdev, bridge, linux-kernel, garrmcnu

On Fri, 22 Jun 2018 07:20:56 +0900 (KST)
David Miller <davem@davemloft.net> wrote:

> From: Garry McNulty <garrmcnu@gmail.com>
> Date: Thu, 21 Jun 2018 21:14:27 +0100
> 
> > br_port_get_rtnl() can return NULL if the network device is not a bridge
> > port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and
> > br_port_fill_slave_info() callbacks dereference this pointer without
> > checking. Currently this is not a problem because slave devices always
> > set this flag. Add null check in case these conditions ever change.
> > 
> > Detected by CoverityScan, CID 1339613 ("Dereference null return value")
> > 
> > Signed-off-by: Garry McNulty <garrmcnu@gmail.com>  
> 
> I don't think this is reasonable.
> 
> The bridge code will never, ever, install a slave that doesn't have
> that bit set.  It's the most fundamental aspect of how these objects
> are managed.

Agree with dave. Workarounds for static tools are ok if they don't introduce
other paths. But if your fix introduces another error path which can never
be reached, it is hurting not helping.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bridge] [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()
@ 2018-06-21 23:21     ` Stephen Hemminger
  0 siblings, 0 replies; 12+ messages in thread
From: Stephen Hemminger @ 2018-06-21 23:21 UTC (permalink / raw)
  To: David Miller; +Cc: jiri, nikolay, netdev, bridge, linux-kernel, garrmcnu

On Fri, 22 Jun 2018 07:20:56 +0900 (KST)
David Miller <davem@davemloft.net> wrote:

> From: Garry McNulty <garrmcnu@gmail.com>
> Date: Thu, 21 Jun 2018 21:14:27 +0100
> 
> > br_port_get_rtnl() can return NULL if the network device is not a bridge
> > port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and
> > br_port_fill_slave_info() callbacks dereference this pointer without
> > checking. Currently this is not a problem because slave devices always
> > set this flag. Add null check in case these conditions ever change.
> > 
> > Detected by CoverityScan, CID 1339613 ("Dereference null return value")
> > 
> > Signed-off-by: Garry McNulty <garrmcnu@gmail.com>  
> 
> I don't think this is reasonable.
> 
> The bridge code will never, ever, install a slave that doesn't have
> that bit set.  It's the most fundamental aspect of how these objects
> are managed.

Agree with dave. Workarounds for static tools are ok if they don't introduce
other paths. But if your fix introduces another error path which can never
be reached, it is hurting not helping.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()
  2018-06-21 22:20   ` [Bridge] " David Miller
  (?)
@ 2018-06-21 23:35     ` Nikolay Aleksandrov
  -1 siblings, 0 replies; 12+ messages in thread
From: Nikolay Aleksandrov @ 2018-06-21 23:35 UTC (permalink / raw)
  To: David Miller, garrmcnu; +Cc: netdev, stephen, jiri, bridge, linux-kernel

On 06/22/2018 01:20 AM, David Miller wrote:
> From: Garry McNulty <garrmcnu@gmail.com>
> Date: Thu, 21 Jun 2018 21:14:27 +0100
> 
>> br_port_get_rtnl() can return NULL if the network device is not a bridge
>> port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and
>> br_port_fill_slave_info() callbacks dereference this pointer without
>> checking. Currently this is not a problem because slave devices always
>> set this flag. Add null check in case these conditions ever changye.
>>
>> Detected by CoverityScan, CID 1339613 ("Dereference null return value")
>>
>> Signed-off-by: Garry McNulty <garrmcnu@gmail.com>
> 
> I don't think this is reasonable.
> 
> The bridge code will never, ever, install a slave that doesn't have
> that bit set.  It's the most fundamental aspect of how these objects
> are managed.
> 
+1

This keeps coming up, here's the previous one:
https://patchwork.ozlabs.org/patch/896046/

Please do a more thorough check if these conditions can actually occur.
In this case, as Dave said, they cannot.

To be explicit as with the patch I mentioned above:
Nacked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>

You can find more info in my reply to the patch above.

Thanks,
 Nik

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()
@ 2018-06-21 23:35     ` Nikolay Aleksandrov
  0 siblings, 0 replies; 12+ messages in thread
From: Nikolay Aleksandrov @ 2018-06-21 23:35 UTC (permalink / raw)
  To: David Miller, garrmcnu; +Cc: netdev, bridge, jiri, linux-kernel

On 06/22/2018 01:20 AM, David Miller wrote:
> From: Garry McNulty <garrmcnu@gmail.com>
> Date: Thu, 21 Jun 2018 21:14:27 +0100
> 
>> br_port_get_rtnl() can return NULL if the network device is not a bridge
>> port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and
>> br_port_fill_slave_info() callbacks dereference this pointer without
>> checking. Currently this is not a problem because slave devices always
>> set this flag. Add null check in case these conditions ever changye.
>>
>> Detected by CoverityScan, CID 1339613 ("Dereference null return value")
>>
>> Signed-off-by: Garry McNulty <garrmcnu@gmail.com>
> 
> I don't think this is reasonable.
> 
> The bridge code will never, ever, install a slave that doesn't have
> that bit set.  It's the most fundamental aspect of how these objects
> are managed.
> 
+1

This keeps coming up, here's the previous one:
https://patchwork.ozlabs.org/patch/896046/

Please do a more thorough check if these conditions can actually occur.
In this case, as Dave said, they cannot.

To be explicit as with the patch I mentioned above:
Nacked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>

You can find more info in my reply to the patch above.

Thanks,
 Nik

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bridge] [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()
@ 2018-06-21 23:35     ` Nikolay Aleksandrov
  0 siblings, 0 replies; 12+ messages in thread
From: Nikolay Aleksandrov @ 2018-06-21 23:35 UTC (permalink / raw)
  To: David Miller, garrmcnu; +Cc: netdev, bridge, jiri, linux-kernel

On 06/22/2018 01:20 AM, David Miller wrote:
> From: Garry McNulty <garrmcnu@gmail.com>
> Date: Thu, 21 Jun 2018 21:14:27 +0100
> 
>> br_port_get_rtnl() can return NULL if the network device is not a bridge
>> port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and
>> br_port_fill_slave_info() callbacks dereference this pointer without
>> checking. Currently this is not a problem because slave devices always
>> set this flag. Add null check in case these conditions ever changye.
>>
>> Detected by CoverityScan, CID 1339613 ("Dereference null return value")
>>
>> Signed-off-by: Garry McNulty <garrmcnu@gmail.com>
> 
> I don't think this is reasonable.
> 
> The bridge code will never, ever, install a slave that doesn't have
> that bit set.  It's the most fundamental aspect of how these objects
> are managed.
> 
+1

This keeps coming up, here's the previous one:
https://patchwork.ozlabs.org/patch/896046/

Please do a more thorough check if these conditions can actually occur.
In this case, as Dave said, they cannot.

To be explicit as with the patch I mentioned above:
Nacked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>

You can find more info in my reply to the patch above.

Thanks,
 Nik

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()
  2018-06-21 23:35     ` Nikolay Aleksandrov
@ 2018-06-22 19:05       ` Garry McNulty
  -1 siblings, 0 replies; 12+ messages in thread
From: Garry McNulty @ 2018-06-22 19:05 UTC (permalink / raw)
  To: nikolay
  Cc: davem, netdev, stephen, Jiří Pírko, bridge, linux-kernel

On Fri, 22 Jun 2018 at 00:35, Nikolay Aleksandrov
<nikolay@cumulusnetworks.com> wrote:
>
> On 06/22/2018 01:20 AM, David Miller wrote:
> > From: Garry McNulty <garrmcnu@gmail.com>
> > Date: Thu, 21 Jun 2018 21:14:27 +0100
> >
> >> br_port_get_rtnl() can return NULL if the network device is not a bridge
> >> port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and
> >> br_port_fill_slave_info() callbacks dereference this pointer without
> >> checking. Currently this is not a problem because slave devices always
> >> set this flag. Add null check in case these conditions ever changye.
> >>
> >> Detected by CoverityScan, CID 1339613 ("Dereference null return value")
> >>
> >> Signed-off-by: Garry McNulty <garrmcnu@gmail.com>
> >
> > I don't think this is reasonable.
> >
> > The bridge code will never, ever, install a slave that doesn't have
> > that bit set.  It's the most fundamental aspect of how these objects
> > are managed.
> >
> +1
>
> This keeps coming up, here's the previous one:
> https://patchwork.ozlabs.org/patch/896046/
>
> Please do a more thorough check if these conditions can actually occur.
> In this case, as Dave said, they cannot.
>
> To be explicit as with the patch I mentioned above:
> Nacked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>
> You can find more info in my reply to the patch above.
>
> Thanks,
>  Nik

Thanks for reviewing and for the feedback.

Regards

Garry

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bridge] [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()
@ 2018-06-22 19:05       ` Garry McNulty
  0 siblings, 0 replies; 12+ messages in thread
From: Garry McNulty @ 2018-06-22 19:05 UTC (permalink / raw)
  To: nikolay; +Cc: Jiří Pírko, netdev, bridge, linux-kernel, davem

On Fri, 22 Jun 2018 at 00:35, Nikolay Aleksandrov
<nikolay@cumulusnetworks.com> wrote:
>
> On 06/22/2018 01:20 AM, David Miller wrote:
> > From: Garry McNulty <garrmcnu@gmail.com>
> > Date: Thu, 21 Jun 2018 21:14:27 +0100
> >
> >> br_port_get_rtnl() can return NULL if the network device is not a bridge
> >> port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and
> >> br_port_fill_slave_info() callbacks dereference this pointer without
> >> checking. Currently this is not a problem because slave devices always
> >> set this flag. Add null check in case these conditions ever changye.
> >>
> >> Detected by CoverityScan, CID 1339613 ("Dereference null return value")
> >>
> >> Signed-off-by: Garry McNulty <garrmcnu@gmail.com>
> >
> > I don't think this is reasonable.
> >
> > The bridge code will never, ever, install a slave that doesn't have
> > that bit set.  It's the most fundamental aspect of how these objects
> > are managed.
> >
> +1
>
> This keeps coming up, here's the previous one:
> https://patchwork.ozlabs.org/patch/896046/
>
> Please do a more thorough check if these conditions can actually occur.
> In this case, as Dave said, they cannot.
>
> To be explicit as with the patch I mentioned above:
> Nacked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>
> You can find more info in my reply to the patch above.
>
> Thanks,
>  Nik

Thanks for reviewing and for the feedback.

Regards

Garry

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2018-06-22 19:06 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-21 20:14 [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl() Garry McNulty
2018-06-21 20:14 ` [Bridge] " Garry McNulty
2018-06-21 22:20 ` David Miller
2018-06-21 22:20   ` [Bridge] " David Miller
2018-06-21 23:21   ` Stephen Hemminger
2018-06-21 23:21     ` [Bridge] " Stephen Hemminger
2018-06-21 23:21     ` Stephen Hemminger
2018-06-21 23:35   ` Nikolay Aleksandrov
2018-06-21 23:35     ` [Bridge] " Nikolay Aleksandrov
2018-06-21 23:35     ` Nikolay Aleksandrov
2018-06-22 19:05     ` Garry McNulty
2018-06-22 19:05       ` [Bridge] " Garry McNulty

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.