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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 21 Apr 2022 21:16:27 -0700
From:   Eric Dumazet <edumazet@...gle.com>
To:     Saeed Mahameed <saeed@...nel.org>
Cc:     Florent Fourcot <florent.fourcot@...irst.fr>,
        netdev <netdev@...r.kernel.org>,
        Cong Wang <cong.wang@...edance.com>,
        Brian Baboch <brian.baboch@...irst.fr>
Subject: Re: [PATCH v3 net-next 4/4] rtnetlink: return EINVAL when request
 cannot succeed

On Thu, Apr 21, 2022 at 8:50 PM Saeed Mahameed <saeed@...nel.org> wrote:
>
> On 05 Apr 15:42, Florent Fourcot wrote:
> >A request without interface name/interface index/interface group cannot
> >work. We should return EINVAL
> >
> >Signed-off-by: Florent Fourcot <florent.fourcot@...irst.fr>
> >Signed-off-by: Brian Baboch <brian.baboch@...irst.fr>
> >---
> > net/core/rtnetlink.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> >index e93f4058cf08..690324479cf5 100644
> >--- a/net/core/rtnetlink.c
> >+++ b/net/core/rtnetlink.c
> >@@ -3420,7 +3420,7 @@ static int __rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh,
> >                       return rtnl_group_changelink(skb, net,
> >                                               nla_get_u32(tb[IFLA_GROUP]),
> >                                               ifm, extack, tb);
> >-              return -ENODEV;
> >+              return -EINVAL;
> >       }
>
> This introduced a regression iproute2->iplink_have_newlink() checks this
> return value to determine if newlink is supported by kernel, if the
> returned value is -EINVAL iproute2 falls back to ioctl mode, any value
> other than -EINVAL or -EOPNOTSUPP should be ok here to not break compatibility
> with iproute2.
>

Yep, but apparently network maintainers are MIA

https://patchwork.kernel.org/project/netdevbpf/patch/20220419125151.15589-1-florent.fourcot@wifirst.fr/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ