On Tue, Apr 25, 2017 at 10:40 PM, Jiri Pirko <j...@resnulli.us> wrote:
> Wed, Apr 26, 2017 at 07:03:23AM CEST, xiyou.wangc...@gmail.com wrote:
>>IPv6 tunnels use sizeof(struct in6_addr) as dev->addr_len,
>>but in many places especially bonding, we use struct sockaddr
>>to copy and set mac addr, this could lead to stack out-of-bounds
>>access.
>>
>>Fix it by using a larger address storage.
>>
>>Reported-by: Andrey Konovalov <andreyk...@google.com>
>>Cc: Jiri Pirko <j...@resnulli.us>
>>Signed-off-by: Cong Wang <xiyou.wangc...@gmail.com>
>>---
>> drivers/net/team/team.c | 9 ++++++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>>diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
>>index 85c0124..88878f1 100644
>>--- a/drivers/net/team/team.c
>>+++ b/drivers/net/team/team.c
>>@@ -60,10 +60,13 @@ static struct team_port *team_port_get_rtnl(const struct
>>net_device *dev)
>> static int __set_port_dev_addr(struct net_device *port_dev,
>> const unsigned char *dev_addr)
>> {
>>- struct sockaddr addr;
>>+ struct {
>>+ unsigned short type;
>>+ unsigned char addr[MAX_ADDR_LEN];
>>+ } addr;
>
> Wouldn't it make sense to define this struct somewhere in the core
> headers?
I _did_ use a struct mac_addr until I found there are multiple places
in the tree already defining it... We are in a similar situation to the union
of struct in_addr and struct in6_addr, unfortunately.
We can always clean up these for net-next.
