From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12887 Path: news.gmane.org!.POSTED!not-for-mail From: Andrei Vagin Newsgroups: gmane.linux.lib.musl.general Subject: Re: Endless loop in netlink_msg_to_ifaddr Date: Sat, 2 Jun 2018 10:36:31 -0700 Message-ID: <20180602173630.GA21659@gmail.com> References: <20180530154529.0bf8f46b@vostro> <20180602014433.GS1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r X-Trace: blaine.gmane.org 1527960884 23838 195.159.176.226 (2 Jun 2018 17:34:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 2 Jun 2018 17:34:44 +0000 (UTC) User-Agent: Mutt/1.9.3 (2018-01-21) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-12903-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 02 19:34:40 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fPAQJ-00067i-Px for gllmg-musl@m.gmane.org; Sat, 02 Jun 2018 19:34:39 +0200 Original-Received: (qmail 3912 invoked by uid 550); 2 Jun 2018 17:36:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3831 invoked from network); 2 Jun 2018 17:36:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=WpazN2E8oqxqMszGgHu7TU3/LEpRb6ez6HVE75Ir/G4=; b=C2aJXRQ1lGrfch01Ml7ueUYQuSq27HHElflwwTswWlgI/wEywVyU2czQV/vd24prUw HOCCtGkfjhytGXd/wGjtt0G/DF+oTUT1YgpsAUfPiGyTxrkpeIRyIfaIJzobH3SqTPY/ rsyPu5aFrmLTaPqAOxzr0Yi+G9ftq+pEyIIsqRQyO2FyGAHrVJgacPdxLXHmmRc+moMI xII60AKXzgOghkLn3M7Xik3is7VmDujXO4O9/CutoDFUsTZgXP8ohKCahbFCRIVOGviZ K0MH8PpKqofp2o47JDcR63Uyq5vM/zNo3lLXDmW5AFeeLPVWd7oYVZsYgJyQnhx6hqGA HVGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=WpazN2E8oqxqMszGgHu7TU3/LEpRb6ez6HVE75Ir/G4=; b=DRP+Gn269oOewJKeP4M1CxieeUh5XTRX7rNdtfCdqVrjZItctN0sonpGZILwteXUzq Bnqup8mx0mUB2zM50d/SECOHOxy3oPUR/4II1j01j58e8uj7xEoy2NVsdum708xaTGfX nUUoLhiI/2eQcMnCWoJUOK4VKzdp9JM0XZg5uYrrMvFjfCVyiOdnNvr0WNqFlZC0/ERO Pv/pNnv3MK6Zy7KuG7qNU+QlpJR3YrPEvy9iJmyW8s4eozuoU/nlPMoN4ZAxRvXBZrVq x7H2N5ptfs4P3gBlh4sCMcf6FfLX16gFMipAJHjlcBBsfO+SSFygbNWGS2SjU7w5F/Xf FBLg== X-Gm-Message-State: ALKqPwfQ69rdtiTILMm8hy4aRy+Df39/0/m160yNBmP61OfBB69dXlRe qF8OqGml5V0fZA0szL9TjLsEBQlb X-Google-Smtp-Source: ADUXVKIKm8QGPe+mKRPZbVe3oZTbV7cog3Ll3DpcLOER1cumosX+AWGKF4q61ywup8JK/vhNsBuCaA== X-Received: by 2002:a17:902:2702:: with SMTP id c2-v6mr15300304plb.297.1527960993951; Sat, 02 Jun 2018 10:36:33 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20180602014433.GS1392@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12887 Archived-At: On Fri, Jun 01, 2018 at 09:44:33PM -0400, Rich Felker wrote: > On Wed, May 30, 2018 at 03:45:29PM +0300, Timo Teras wrote: > > On Wed, 30 May 2018 11:57:03 +0200 > > Matej Kupljen wrote: > > > > > I am using OpenWRT device with MUSL C library version 1.1.19 and I am > > > running custom binary on it. I noticed that during testing my program > > > started using 99% CPU. > > > I build OpenWRT myself so I have all the sources. I attached the > > > gdbserver and checked what is going on. > > > > Thanks for the report! > > > > > As you can see the first message in netlink reply has a rta_len set > > > to zero so the list is never traversed, only the first message is > > > received every time. > > > > > > I am not sure if this is the correct response from netlink, however > > > the program is stucked here. > > > > > > Any ideas? > > > Please CC me in reply. > > > > That is invalid message to my understanding. Perhaps there's some new > > extensions that allow it. Upstream (linux kernel) RTA_OK does do > > additional checks against this situation. > > > > The same issue probably affects if_nameindex. > > > > I think the following should fix it: > > > > diff --git a/src/network/netlink.h b/src/network/netlink.h > > index 20700ac5..00dc7172 100644 > > --- a/src/network/netlink.h > > +++ b/src/network/netlink.h > > @@ -80,13 +80,13 @@ struct ifaddrmsg { > > #define NLMSG_DATALEN(nlh) ((nlh)->nlmsg_len-sizeof(struct nlmsghdr)) > > #define NLMSG_DATAEND(nlh) ((char*)(nlh)+(nlh)->nlmsg_len) > > #define NLMSG_NEXT(nlh) (struct nlmsghdr*)((char*)(nlh)+NETLINK_ALIGN((nlh)->nlmsg_len)) > > -#define NLMSG_OK(nlh,end) ((char*)(end)-(char*)(nlh) >= sizeof(struct nlmsghdr)) > > +#define NLMSG_OK(nlh,end) ((char*)(end)-(char*)(nlh) >= sizeof(struct nlmsghdr) && (nlh)->nlmsg_len >= sizeof(struct nlmsghdr)) Here is an example of the same macros from the kernel sources: include/uapi/linux/netlink.h: #define NLMSG_OK(nlh,len) ((len) >= (int)sizeof(struct nlmsghdr) && \ (nlh)->nlmsg_len >= sizeof(struct nlmsghdr) && \ (nlh)->nlmsg_len <= (len)) It contains one more expression to check that an end of a message is in a buffer. I think it makes sense to add this expression too. > > > > #define RTA_DATA(rta) ((void*)((char*)(rta)+sizeof(struct rtattr))) > > #define RTA_DATALEN(rta) ((rta)->rta_len-sizeof(struct rtattr)) > > #define RTA_DATAEND(rta) ((char*)(rta)+(rta)->rta_len) > > #define RTA_NEXT(rta) (struct rtattr*)((char*)(rta)+NETLINK_ALIGN((rta)->rta_len)) > > -#define RTA_OK(nlh,end) ((char*)(end)-(char*)(rta) >= sizeof(struct rtattr)) > > +#define RTA_OK(rta,end) ((char*)(end)-(char*)(rta) >= sizeof(struct rtattr) && (rta)->rta_len >= sizeof(struct rtattr)) #define RTA_OK(rta,len) ((len) >= (int)sizeof(struct rtattr) && \ (rta)->rta_len >= sizeof(struct rtattr) && \ (rta)->rta_len <= (len)) > > > > #define NLMSG_RTA(nlh,len) ((void*)((char*)(nlh)+sizeof(struct nlmsghdr)+NETLINK_ALIGN(len))) > > #define NLMSG_RTAOK(rta,nlh) RTA_OK(rta,NLMSG_DATAEND(nlh)) > > > > > > Could you try if this fixes it? > > I'm still waiting to hear whether this fixed it. > > > You will probably need to 'make clean' or at least force recompilation > > of src/network/{getifaddrs,if_nameindex,netlink}.c as the netlink.h > > dependency is not picked up by the makefile automatically. > > > > @dalias, if the above looks good to you, I am happy to submit properly > > formatted git patch for it. > > I don't see anything obvious wrong with the proposed patch, but it > would be nice to have a better understanding of why it's needed and > whether this is a workaround for a kernel bug (present in which > kernels?) or something else. > > Rich