netdev - Re: [PATCH net-next] netlink: correct nlmsg size for multicast notifications

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89i+SMrCH1XqL8Q9-rr7k2bez1DNqeQNhO0rBrrHiyOrFXw@mail.gmail.com>
Date: Thu, 19 Dec 2024 14:47:38 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Yuyang Huang <yuyanghuang@...gle.com>
Cc: "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, David Ahern <dsahern@...nel.org>, 
	roopa@...ulusnetworks.com, jiri@...nulli.us, stephen@...workplumber.org, 
	jimictw@...gle.com, prohr@...gle.com, liuhangbin@...il.com, 
	nicolas.dichtel@...nd.com, andrew@...n.ch, pruddy@...tta.att-mail.com, 
	netdev@...r.kernel.org, Maciej Żenczykowski <maze@...gle.com>, 
	Lorenzo Colitti <lorenzo@...gle.com>
Subject: Re: [PATCH net-next] netlink: correct nlmsg size for multicast notifications

On Thu, Dec 19, 2024 at 2:42 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Thu, Dec 19, 2024 at 2:27 PM Yuyang Huang <yuyanghuang@...gle.com> wrote:
> >
> > Corrected the netlink message size calculation for multicast group
> > join/leave notifications. The previous calculation did not account for
> > the inclusion of both IPv4/IPv6 addresses and ifa_cacheinfo in the
> > payload. This fix ensures that the allocated message size is
> > sufficient to hold all necessary information.
> >
> > Fixes: 2c2b61d2138f ("netlink: add IGMP/MLD join/leave notifications")
> > Cc: Maciej Żenczykowski <maze@...gle.com>
> > Cc: Lorenzo Colitti <lorenzo@...gle.com>
> > Signed-off-by: Yuyang Huang <yuyanghuang@...gle.com>
> > ---
> >  net/ipv4/igmp.c  | 4 +++-
> >  net/ipv6/mcast.c | 4 +++-
> >  2 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> > index 8a370ef37d3f..4e2f1497f320 100644
> > --- a/net/ipv4/igmp.c
> > +++ b/net/ipv4/igmp.c
> > @@ -1473,7 +1473,9 @@ static void inet_ifmcaddr_notify(struct net_device *dev,
> >         int err = -ENOMEM;
> >
> >         skb = nlmsg_new(NLMSG_ALIGN(sizeof(struct ifaddrmsg)) +
> > -                       nla_total_size(sizeof(__be32)), GFP_ATOMIC);
> > +                       nla_total_size(sizeof(__be32)) +
> > +                       nla_total_size(sizeof(struct ifa_cacheinfo)),
> > +                       GFP_ATOMIC);
> >         if (!skb)
> >                 goto error;
> >
> > diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
> > index 587831c148de..b7430f15d1fc 100644
> > --- a/net/ipv6/mcast.c
> > +++ b/net/ipv6/mcast.c
> > @@ -920,7 +920,9 @@ static void inet6_ifmcaddr_notify(struct net_device *dev,
> >         int err = -ENOMEM;
> >
> >         skb = nlmsg_new(NLMSG_ALIGN(sizeof(struct ifaddrmsg)) +
> > -                       nla_total_size(16), GFP_ATOMIC);
> > +                       nla_total_size(16) +
>
> While we are at it , can you use nla_total_size(sizeof(struct in6_addr))
>
> inet6_fill_ifmcaddr() got  an EXPORT_SYMBOL() for no good reason,
> please remove it.
> Squash the following in v2, thanks !
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 2e2684886953d55140cd3d4a1e024b5218331a49..4da409bc45777f60fd37bdee541c61165a51d22c
> 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -5239,7 +5239,6 @@ int inet6_fill_ifmcaddr(struct sk_buff *skb,
>         nlmsg_end(skb, nlh);
>         return 0;
>  }
> -EXPORT_SYMBOL(inet6_fill_ifmcaddr);
>
>  static int inet6_fill_ifacaddr(struct sk_buff *skb,
>                                const struct ifacaddr6 *ifaca,

Also GFP_ATOMIC should probably be replaced by GFP_KERNEL.

All inet6_ifmcaddr_notify() callers are in process context, hold RTNL,
thus can sleep under memory pressure.

Same remark for inet_ifmcaddr_notify()