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 <redacted>
---
net/bridge/br_netlink.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
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 <redacted>
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.
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 <redacted>
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.
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 <redacted>
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 [off-list ref]
You can find more info in my reply to the patch above.
Thanks,
Nik
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 <redacted>
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 [off-list ref]
You can find more info in my reply to the patch above.
Thanks,
Nik
Thanks for reviewing and for the feedback.
Regards
Garry