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>] [day] [month] [year] [list]
Date:   Thu, 3 Mar 2022 10:29:43 +0000
From:   Шумник Алексей <ashumnik@...erra.ru>
To:     "'netdev@...r.kernel.org'" <'netdev@...r.kernel.org'>
Subject: [bug report] ip neigh: ipv6 as lladdr

Dear Maintainers,

I'm developing NHRP with IPv6 support as NBMA, at one stage I need to create an entry in the neighbors table, and I found a bug:
When I add an IPv4 address, everything works fine:

$ ip n add 10.10.10.100 dev mgre0 lladdr 10.10.106.123

But when I perform the same actions with IPv6:

$ ip -6 n add 2001::100 dev enp0s3 lladdr fd0e:a00:a7ff::fee1:99f5

get an error: "fd0e" is invalid lladdr
I realized that ip utility does not know how to add IPv6 addresses to the neighbors list as lladdr. 
I use this code to add IPv6 as lladdr to neighbors list and it's working, but it seems that kernel can't read this entry correctly.

    int kernel_inject_neighbor(struct nhrp_address *neighbor,

                                                   struct nhrp_address *hwaddr,

                                                   struct nhrp_interface *dev)

    {

                   struct {

                                   struct nlmsghdr                n;

                                   struct ndmsg                     ndm;

                                   char                                      buf[256];

                   } req;

                   char neigh[MAX_BUFF_SIZE], nbma[MAX_BUFF_SIZE];

                   memset(&req.n, 0, sizeof(req.n));

                   memset(&req.ndm, 0, sizeof(req.ndm));

                   req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct ndmsg));

                   req.n.nlmsg_flags = NLM_F_REQUEST | NLM_F_REPLACE | NLM_F_CREATE;

                   req.n.nlmsg_type = RTM_NEWNEIGH;

                   req.ndm.ndm_family = neighbor->type;

                   req.ndm.ndm_ifindex = dev->index;

                   req.ndm.ndm_type = RTN_UNICAST;

                   netlink_add_rtattr_l(&req.n, sizeof(req), NDA_DST,

                                                                   (char *)&neighbor->addr, neighbor->addr_len);

                   if (hwaddr != NULL && hwaddr->type != PF_UNSPEC) {

                                   req.ndm.ndm_state = NUD_REACHABLE;

                                   netlink_add_rtattr_l(&req.n, sizeof(req), NDA_LLADDR,

                                                                                                                  (char *)&hwaddr->addr, hwaddr->addr_len);

                                   nhrp_debug("NL-NEIGH(%s) %s is-at %s",

                                                   dev->name,

                                                   nhrp_address_format(neighbor, sizeof(neigh), neigh),

                                                   nhrp_address_format(hwaddr, sizeof(nbma), nbma));

                   } else {

                                   req.ndm.ndm_state = NUD_FAILED;

                                   nhrp_debug("NL-NEIGN(%s) %s not-reachable",

                                                   dev->name,

                                                   nhrp_address_format(neighbor, sizeof(neigh), neigh));

                   }

                   return netlink_send(&talk_fd, &req.n);

    }

Is this a bug and will it be fixed? How long will it take to fix this bug? 
If I try to fix it myself, then where to start and where to look?

--
Aleksey Shumnik

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ