netdev - Re: iproute2: no error message when link up command fails.

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]

Date:	Thu, 17 Jul 2008 11:26:38 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Andreas Henriksson <andreas@...al.se>
CC:	Stephen Hemminger <shemminger@...tta.com>,
	Johannes Berg <johannes@...solutions.net>,
	stephen.hemminger@...tta.com, 489340@...s.debian.org,
	netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>
Subject: Re: iproute2: no error message when link up command fails.

Andreas Henriksson wrote:
> On ons, 2008-07-16 at 15:53 -0700, Stephen Hemminger wrote:
>> The netlink message in question is marked as type ERROR but the errno
>> encoded in the message is zero.
>>
>> 		if (h->nlmsg_type == NLMSG_ERROR) {
>> 			struct nlmsgerr *err = (struct nlmsgerr*)NLMSG_DATA(h);
>> 			if (l < sizeof(struct nlmsgerr)) {
>> 				fprintf(stderr, "ERROR truncated\n");
>> 			} else {
>> 				errno = -err->error;
>> 				if (errno == 0) {
>> 					if (answer)
>> 						memcpy(answer, h, h->nlmsg_len);
>> 					return 0;
>> 				}
>> 				perror("RTNETLINK answers");
>> 			}
>>
>> So the netlink library just treats as a successful return.
> Why? This seems like a really bad idea to me, and none of the callers in
> iproute benefits from this as far as I can see.
> 
> Just ripping out the errno == 0 special casing looks like and option to
> me, unless anyone can find a reason for it.

NLMSG_ERROR with errno == 0 is a netlink ACK message.

> (It'll give an error message and an error exit code! The message will be
> strange, but lets blame the kernel for that cosmetic issue. Atleast the
> user got some kind of notification.)
> 
> Moving the "return 0;" inside the "if (answer)" would be another
> (atleast for iproutes callers of the library functions)...
> 
>> To me it looks like the problem is in the kernel sending back
>> a NLMSG_ERROR with errno of zero. Some code path isn't setting
>> it up properly.
> 
> None the less, it would be be good if the application wouldn't poop it's
> pants when it can be avoided - broken kernel or not.

The fix in this case is to propagate the return value from
dev_change_flags().



View attachment "x" of type "text/plain" (785 bytes)