netdev - Re: Doing specific RTM_GETLINK or RTM

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, 27 Jun 2013 00:23:30 +0100
From:	Thomas Graf <tgraf@...g.ch>
To:	Philip Prindeville <philipp_subx@...fish-solutions.com>
Cc:	libnl@...ts.infradead.org, netdev@...r.kernel.org
Subject: Re: Doing specific RTM_GETLINK or RTM_GETADDR

CCed netdev as this is ultimatively a kernel issue

On 06/24/13 at 01:42pm, Philip Prindeville wrote:
> I couldn't find documentation that said specifically if one can do a NLM_F_REQUEST | NLM_F_MATCH on a specific ifindex for an RTM_GETLINK or RTM_GETADDR.
> 
> I'm running Fedora (3.9.4) but also some older versions including uClinux and 2.6.39 (embedded) where this needs to work as well.
> 
> Even the following trivial query:
> 
> 	msg = (struct nlmsghdr *) buf;
> 	memset(msg, 0, sizeof(*msg));
> 
> 	msg->nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
> 	msg->nlmsg_type = RTM_GETLINK;
> 	msg->nlmsg_flags = NLM_F_REQUEST | NLM_F_MATCH;
> 	msg->nlmsg_pid = 0;
> 	msg->nlmsg_seq = iter->seq++;
> 
> 	NLMSG_DUMP(msg, "send2");
> 
> 	info = (struct ifinfomsg *) NLMSG_DATA(msg);
> 	memset(info, 0, sizeof(*info));
> 
> 	info->ifi_family = AF_NETLINK;
> 	info->ifi_index = iter->ifindex;
> 
> 
> results in ALL of the interfaces being reported back (ditto for RTM_GETADDR). So if the NLM_F_MATCH flag doesn't control that, I don't understand what does.
> 
> Also, I was looking for documentation about (1) what version IFLA_AF_SPEC was introduced, and (2) how to parse it but I couldn't find that either.
> 
> If this isn't the correct place to ask, please let me know. 

This is a bug that dates back as long as Netlink exists. What
would be expected:

NLM_F_MATCH: Return single match
NLM_F_DUMP: Dump complete tree

The following still makes sense:
NLM_F_DUMP = (NLM_F_ROOT | NLM_F_MATCH)

The problem is this:
net/core/rtnetlink.c:   if (kind == 2 && nlh->nlmsg_flags&NLM_F_DUMP)

So if either NLM_F_MATCH or NLM_F_DUMP is set we dump the complete
tree. I have classified this as bug when I saw it but there is not
much we can do. A lot of applications expect it to behave like that.
Changing it now might break a lot.

Workaround is to leave otu NLM_F_MATCH alltogether, that will
result in a single match.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html