From patchwork Thu Sep 27 17:58:51 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 975838 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=brauner.io Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=brauner.io header.i=@brauner.io header.b="ZheSHKsU"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 42LjHv1WBbz9s1x for ; Fri, 28 Sep 2018 03:59:39 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728513AbeI1AS7 (ORCPT ); Thu, 27 Sep 2018 20:18:59 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:41188 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728493AbeI1AS7 (ORCPT ); Thu, 27 Sep 2018 20:18:59 -0400 Received: by mail-ed1-f65.google.com with SMTP id f38-v6so5849495edd.8 for ; Thu, 27 Sep 2018 10:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=3Gm1dPbYL0xuWI3ULCZGB4Vn02KOLqVYdbubTdPf5ew=; b=ZheSHKsUDX2/1ui/M2Yeg4XuaxwFUUTmEDORywTuVokXhCdLo/yotzId22FYT+VlmK 0W6/4zDphgvue2HpAHDwYEPdQNrE2NfQ1tuIdzz6Oh/LExymYMcjCcf9GYHDiKKEhZFJ 6wGXNLM2u8lNWKhKiu4Wkz6g3bhWZkqzrjC/G0PAHuT4FR9bx4R2QNSJmYI8qF6LZL3N LtJJe4hff6KkKeD+fTGJFQS7wpVoG33dUB8cc93PJ4tWrO7rUzx4GpN6bisi4yGHxAot vKIhFYNkfqqTzDJNdx8Cn7JV1yMFf4ERWT1euDiQ8vE3QffcnU5GdPMRqyXSqiyW2S6l oi3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=3Gm1dPbYL0xuWI3ULCZGB4Vn02KOLqVYdbubTdPf5ew=; b=BxXbmqah76N48+5mvtmuPrSu4siZxFsFbNkrSPlqp/4kp6/tSLr8cUd/ctM8kkkhgj hA/jy/wXFdDjHBPYoqnzTyyy+OOJsWfKHQp57EFD+QPsvHCcPv6g4tGxtIC8NFALqSyk VNcS/8O5bRNaah9DKO+NKBMsbNp7YqvwOHu75DCxYpn4Uy+KjGkeYJ6HKWzm2P/+375M UyZHldqBlZUAy34wjG3JZhaBdTc9mxdBKxZ37Q6XnI0ghNcHt5nmcvAdflehhx35wgS1 vMg0xp+wi8uLaVULgJucW4BJbxEr5DHSfA9kcJZNRnHYLBQ1S0cqH7Qe8rKFpRAyH9PX Q8hQ== X-Gm-Message-State: ABuFfogVsulg3NHHrZuj3YotLuDWjmEW/wJlvvG9vhwSW4kTt6ASmSbq x98y9SpqYzJCOtPibHUX/VFQgQ== X-Google-Smtp-Source: ACcGV631gh+1sj/PQuri3kacPfaUvUYLBDQmVJ7GhLLEdEli06pSzXZJZlmipigegxeMLVdIm8uK6Q== X-Received: by 2002:a50:d307:: with SMTP id g7-v6mr7366256edh.221.1538071172070; Thu, 27 Sep 2018 10:59:32 -0700 (PDT) Received: from localhost.localdomain (fa-padur-binz.ediscom.de. [212.204.40.18]) by smtp.gmail.com with ESMTPSA id a9-v6sm1532606edi.26.2018.09.27.10.59.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 10:59:31 -0700 (PDT) From: Christian Brauner To: jbenc@redhat.com, davem@davemloft.net, dsahern@gmail.com, stephen@networkplumber.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Christian Brauner Subject: [PATCH net-next 1/7] rtnetlink: add RTM_GETADDR2 Date: Thu, 27 Sep 2018 19:58:51 +0200 Message-Id: <20180927175857.3511-2-christian@brauner.io> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180927175857.3511-1-christian@brauner.io> References: <20180927175857.3511-1-christian@brauner.io> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Various userspace programs (e.g. iproute2) have sent RTM_GETADDR requests with struct ifinfomsg. This is wrong and should have been struct ifaddrmsg all along as mandated by the manpages. However, dump requests so far didn't parse the netlink message that was sent and succeeded even when a wrong struct was passed along. Currently, the message is parsed under the assumption that the correct struct ifaddrmsg is sent down. If the parsing fails the kernel will still fulfill the request to preserve backwards compatability but a rate-limited message that there were leftover bytes after parsing the message is recorded in dmesg. It has been argued that this is unacceptable [1]. But various new features that got and will get added to RTM_GETADDR make it necessary to definitely know what header was passed along. This is currently not possible without resorting to (likely unreliable) hacks such as introducing a nested attribute that ensures that RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID always exceed RTM_GETADDR requests that send down the wrong struct ifinfomsg [2]. Basically, multiple approaches to solve this have been shut down. Furthermore, the API expressed via RTM_GETADDR is apparently frozen [3] so the wiggle room at this point seems very much zero. The correct solution at this point seems to me to introduce a new RTM_GETADDR2 request. This way we can parse the message and fail hard if the struct is not struct ifaddrmsg and can safely extend it in the future. Userspace tools that rely on the buggy RTM_GETADDR API will still keep working without even having to see any log messages and new userspace tools that want to make user of new features can make use of the new RTM_GETADDR2 requests. [1]: https://lists.openwall.net/netdev/2018/09/25/59 [2]: https://lists.openwall.net/netdev/2018/09/25/75 [3]: https://lists.openwall.net/netdev/2018/09/26/166 Signed-off-by: Christian Brauner Cc: David Ahern Cc: Jiri Benc Cc: Stephen Hemminger --- include/uapi/linux/rtnetlink.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h index 46399367627f..e167f90c3d7a 100644 --- a/include/uapi/linux/rtnetlink.h +++ b/include/uapi/linux/rtnetlink.h @@ -157,6 +157,9 @@ enum { RTM_GETCHAIN, #define RTM_GETCHAIN RTM_GETCHAIN + RTM_GETADDR2 = 106, +#define RTM_GETADDR2 RTM_GETADDR2 + __RTM_MAX, #define RTM_MAX (((__RTM_MAX + 3) & ~3) - 1) }; From patchwork Thu Sep 27 17:58:52 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 975844 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=brauner.io Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=brauner.io header.i=@brauner.io header.b="UjTu3nIc"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 42LjJs6t76z9s1x for ; Fri, 28 Sep 2018 04:00:29 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728582AbeI1ATC (ORCPT ); Thu, 27 Sep 2018 20:19:02 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:46874 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728493AbeI1ATB (ORCPT ); Thu, 27 Sep 2018 20:19:01 -0400 Received: by mail-ed1-f65.google.com with SMTP id k14-v6so5827948edr.13 for ; Thu, 27 Sep 2018 10:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=r8s+hMtRCFiHF8UTr+Vfz9PSgRGWsmuR5zLQAqOls3M=; b=UjTu3nIc/7btaPWoHETV7jAM4+Uf6QRJurgajGDJkcYnekW0HQ7bhbjMa+EDmQGrwr 9dJJiGce3sIHDxpy5iTT2reo39X6Yw5LkzdGnDhsHnJ5Mxe13VoT7kWl74z6xZvvPw+C 4fn8qEQNkVTC1GPVfC8BlwFI5EThz0JHtjZsDciHR4lf+FtN19+WmjvlwB5cbAOvTQ7i XRY88LVB6NSdyWrfEswkKfeLbPk56zY5LHgjgtzM8tUgLwqkLYsS8x+5D27JJXF7Smi5 H6Xt9HOaj3FPwmyk3T1znbVvhQE7cA+mpGtdqlxvxdZ9y9INUByuNVYdu3IvbBuv7yrj U8LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=r8s+hMtRCFiHF8UTr+Vfz9PSgRGWsmuR5zLQAqOls3M=; b=j8r1nlU3qf1KsrhBwVC8NEA8p/6SpBVBSID1eCgJIHwNMwGv9IJkyhdNWF0Z2TdrVE P1OB8tYxoyIUx7ycFZ+leYuaKEzGx294QkfN6xFnkul7A52JnrZKgxLyACBYsaErahCR k47ufYxoQy2KCT5IgQAJbKNAKVlW648wywsmW5PFBEWgbs+vXo/9IlWm0GuDhgf8tj0h ICA53EKlV8TjVboeREeElWV/WdpuCklzCLcpMmmOTBMnSvLYnmwK9+qXzJ+9GwiJXHnj 9GO55I7tX6IKhqi/rtyXZk1Iv3GeMeBW0GL4cEOYYZKjXxkf7n8psXf7QcnRwIf1t5EZ 4HHQ== X-Gm-Message-State: ABuFfog58/PwBxYI+hndbAFggBx3z4rCz1z3XHUBymrlnYRvnadRChqD AWuY6KGd89vdxsEPVv2dZ1a1mw== X-Google-Smtp-Source: ACcGV62pR3/e85N26b+4kx2e3ciZbnG3iU7m33B0rFESKuqclNcRq+fuXoihUkIU+tVsqNW/zrTxCA== X-Received: by 2002:a50:ac76:: with SMTP id w51-v6mr19421250edc.211.1538071173722; Thu, 27 Sep 2018 10:59:33 -0700 (PDT) Received: from localhost.localdomain (fa-padur-binz.ediscom.de. [212.204.40.18]) by smtp.gmail.com with ESMTPSA id a9-v6sm1532606edi.26.2018.09.27.10.59.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 10:59:32 -0700 (PDT) From: Christian Brauner To: jbenc@redhat.com, davem@davemloft.net, dsahern@gmail.com, stephen@networkplumber.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Christian Brauner Subject: [PATCH net-next 2/7] ipv4: add RTM_GETADDR2 Date: Thu, 27 Sep 2018 19:58:52 +0200 Message-Id: <20180927175857.3511-3-christian@brauner.io> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180927175857.3511-1-christian@brauner.io> References: <20180927175857.3511-1-christian@brauner.io> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Various userspace programs (e.g. iproute2) have sent RTM_GETADDR requests with struct ifinfomsg. This is wrong and should have been struct ifaddrmsg all along as mandated by the manpages. However, dump requests so far didn't parse the netlink message that was sent and succeeded even when a wrong struct was passed along. Currently, the message is parsed under the assumption that the correct struct ifaddrmsg is sent down. If the parsing fails the kernel will still fulfill the request to preserve backwards compatability but a rate-limited message that there were leftover bytes after parsing the message is recorded in dmesg. It has been argued that this is unacceptable [1]. But various new features that got and will get added to RTM_GETADDR make it necessary to definitely know what header was passed along. This is currently not possible without resorting to (likely unreliable) hacks such as introducing a nested attribute that ensures that RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID always exceed RTM_GETADDR requests that send down the wrong struct ifinfomsg [2]. Basically, multiple approaches to solve this have been shut down. Furthermore, the API expressed via RTM_GETADDR is apparently frozen [3] so the wiggle room at this point seems very much zero. The correct solution at this point seems to me to introduce a new RTM_GETADDR2 request. This way we can parse the message and fail hard if the struct is not struct ifaddrmsg and can safely extend it in the future. Userspace tools that rely on the buggy RTM_GETADDR API will still keep working without even having to see any log messages and new userspace tools that want to make user of new features can make use of the new RTM_GETADDR2 requests. [1]: https://lists.openwall.net/netdev/2018/09/25/59 [2]: https://lists.openwall.net/netdev/2018/09/25/75 [3]: https://lists.openwall.net/netdev/2018/09/26/166 Signed-off-by: Christian Brauner Cc: David Ahern Cc: Jiri Benc Cc: Stephen Hemminger --- net/ipv4/devinet.c | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c index 44d931a3cd50..3ac004ba67b0 100644 --- a/net/ipv4/devinet.c +++ b/net/ipv4/devinet.c @@ -1659,7 +1659,8 @@ static int inet_fill_ifaddr(struct sk_buff *skb, struct in_ifaddr *ifa, return -EMSGSIZE; } -static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) +static int inet_dump_ifaddr_common(struct sk_buff *skb, + struct netlink_callback *cb, int rtm_type) { struct inet_fill_args fillargs = { .portid = NETLINK_CB(cb->skb).portid, @@ -1683,8 +1684,14 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) s_idx = idx = cb->args[1]; s_ip_idx = ip_idx = cb->args[2]; - if (nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, IFA_MAX, - ifa_ipv4_policy, NULL) >= 0) { + if (rtm_type == RTM_GETADDR2) { + int err; + + err = nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, + IFA_MAX, ifa_ipv4_policy, NULL); + if (err < 0) + return err; + if (tb[IFA_TARGET_NETNSID]) { fillargs.netnsid = nla_get_s32(tb[IFA_TARGET_NETNSID]); @@ -1736,6 +1743,16 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) return skb->len; } +static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) +{ + return inet_dump_ifaddr_common(skb, cb, RTM_GETADDR); +} + +static int inet_dump_ifaddr2(struct sk_buff *skb, struct netlink_callback *cb) +{ + return inet_dump_ifaddr_common(skb, cb, RTM_GETADDR2); +} + static void rtmsg_ifa(int event, struct in_ifaddr *ifa, struct nlmsghdr *nlh, u32 portid) { @@ -2564,6 +2581,7 @@ void __init devinet_init(void) rtnl_register(PF_INET, RTM_NEWADDR, inet_rtm_newaddr, NULL, 0); rtnl_register(PF_INET, RTM_DELADDR, inet_rtm_deladdr, NULL, 0); rtnl_register(PF_INET, RTM_GETADDR, NULL, inet_dump_ifaddr, 0); + rtnl_register(PF_INET, RTM_GETADDR2, NULL, inet_dump_ifaddr2, 0); rtnl_register(PF_INET, RTM_GETNETCONF, inet_netconf_get_devconf, inet_netconf_dump_devconf, 0); } From patchwork Thu Sep 27 17:58:53 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 975839 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=brauner.io Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=brauner.io header.i=@brauner.io header.b="OCDuvR0J"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 42LjHx5538z9sCK for ; Fri, 28 Sep 2018 03:59:41 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728622AbeI1ATD (ORCPT ); Thu, 27 Sep 2018 20:19:03 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:38416 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727599AbeI1ATD (ORCPT ); Thu, 27 Sep 2018 20:19:03 -0400 Received: by mail-ed1-f66.google.com with SMTP id x8-v6so5867811eds.5 for ; Thu, 27 Sep 2018 10:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=1ZxZ6GmgbBvekGI3np6+PbuOz+YR16wGAjG+yoq1uZk=; b=OCDuvR0JCHxbs0pidAPtFr+mT8UkgCBm74TqW0FHRdQnhEu2zrbmfCNcffUHjfsiHl hxnJHo/NZjcnCUWtAvGxo2f8UdyZrISLgWduN+Jtuyi4IzhNNP4Z9RfXqO5Anrrm7rQb x6vnNClhShCaNoj+PAzZHRmKC7cmzhh+FA15H64uJ8wcn6GJp3jDfxOSFIN5aAMBoGNC Cwqy1ZD90e41wvcCcs2s0RMNjqESJQhdcLEBUk+9XRvIie7Yzc5DUmnbdx/tJl93eQND vkIyHovYwkkm9lK96xLiLnjkvyobSGEmpzhBxEa6ulu0uU/KXFDHEnFfV0i2gRMYxfTu jvIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=1ZxZ6GmgbBvekGI3np6+PbuOz+YR16wGAjG+yoq1uZk=; b=AMdiMNa5kaJUNiCFnaJ4Nvjb831T6yHyeUyvJKnapEXiqO0vG0MrFZEbSilXDJ8RG6 uYInhqevR+34SlHw1BzVobVqLsPWGkXDAW1FLen+POsweBkomkfA0bVXPbgFV+JR8GCV Nz3q2AuR3c4FE7hz7TqZ88JbP/OKJnfq4Gw8d867GcnhCXWXP+iEpUTI22QvyAd33mRZ pGvKeBpq+746jWTjci3Nv6VIpNPDJA5WD2m3ZEPN0R/H6PwVjS1fMBe95eoK+W7MysRT x/jZZOMK/uff6Wz+Dt5ifU98jnv3C26JqCsxnOG/isFASQllSQQUNK0p84+bHAYEBH9p nfKA== X-Gm-Message-State: ABuFfoiWprFnyqkP3lVXxO8vizSGZsj7qTgbMpRJ41WmaEO0J4W+Ecwh tR8563jzvGFsIQ011NHKIDzduIG+XOGmug== X-Google-Smtp-Source: ACcGV62w1TcgsWnjv2vD003hvLRz5V1VCKCXuIycvIGLXJqWEUNNJgEvzSushXBXsPl8ObfgDma3WQ== X-Received: by 2002:a50:d58f:: with SMTP id v15-v6mr2788499edi.226.1538071175444; Thu, 27 Sep 2018 10:59:35 -0700 (PDT) Received: from localhost.localdomain (fa-padur-binz.ediscom.de. [212.204.40.18]) by smtp.gmail.com with ESMTPSA id a9-v6sm1532606edi.26.2018.09.27.10.59.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 10:59:34 -0700 (PDT) From: Christian Brauner To: jbenc@redhat.com, davem@davemloft.net, dsahern@gmail.com, stephen@networkplumber.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Christian Brauner Subject: [PATCH net-next 3/7] ipv6: add RTM_GETADDR2 Date: Thu, 27 Sep 2018 19:58:53 +0200 Message-Id: <20180927175857.3511-4-christian@brauner.io> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180927175857.3511-1-christian@brauner.io> References: <20180927175857.3511-1-christian@brauner.io> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Various userspace programs (e.g. iproute2) have sent RTM_GETADDR requests with struct ifinfomsg. This is wrong and should have been struct ifaddrmsg all along as mandated by the manpages. However, dump requests so far didn't parse the netlink message that was sent and succeeded even when a wrong struct was passed along. Currently, the message is parsed under the assumption that the correct struct ifaddrmsg is sent down. If the parsing fails the kernel will still fulfill the request to preserve backwards compatability but a rate-limited message that there were leftover bytes after parsing the message is recorded in dmesg. It has been argued that this is unacceptable [1]. But various new features that got and will get added to RTM_GETADDR make it necessary to definitely know what header was passed along. This is currently not possible without resorting to (likely unreliable) hacks such as introducing a nested attribute that ensures that RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID always exceed RTM_GETADDR requests that send down the wrong struct ifinfomsg [2]. Basically, multiple approaches to solve this have been shut down. Furthermore, the API expressed via RTM_GETADDR is apparently frozen [3] so the wiggle room at this point seems very much zero. The correct solution at this point seems to me to introduce a new RTM_GETADDR2 request. This way we can parse the message and fail hard if the struct is not struct ifaddrmsg and can safely extend it in the future. Userspace tools that rely on the buggy RTM_GETADDR API will still keep working without even having to see any log messages and new userspace tools that want to make user of new features can make use of the new RTM_GETADDR2 requests. [1]: https://lists.openwall.net/netdev/2018/09/25/59 [2]: https://lists.openwall.net/netdev/2018/09/25/75 [3]: https://lists.openwall.net/netdev/2018/09/26/166 Signed-off-by: Christian Brauner Cc: David Ahern Cc: Jiri Benc Cc: Stephen Hemminger --- net/ipv6/addrconf.c | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index a9a317322388..6e76e5cc76c4 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -5003,7 +5003,7 @@ static int in6_dump_addrs(struct inet6_dev *idev, struct sk_buff *skb, } static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb, - enum addr_type_t type) + enum addr_type_t type, int rtm_version) { struct net *net = sock_net(skb->sk); struct nlattr *tb[IFA_MAX+1]; @@ -5020,8 +5020,14 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb, s_idx = idx = cb->args[1]; s_ip_idx = ip_idx = cb->args[2]; - if (nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, IFA_MAX, - ifa_ipv6_policy, NULL) >= 0) { + if (rtm_version == RTM_GETADDR2) { + int err; + + err = nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, + IFA_MAX, ifa_ipv6_policy, NULL); + if (err < 0) + return err; + if (tb[IFA_TARGET_NETNSID]) { netnsid = nla_get_s32(tb[IFA_TARGET_NETNSID]); @@ -5068,14 +5074,21 @@ static int inet6_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) { enum addr_type_t type = UNICAST_ADDR; - return inet6_dump_addr(skb, cb, type); + return inet6_dump_addr(skb, cb, type, RTM_GETADDR); +} + +static int inet6_dump_ifaddr2(struct sk_buff *skb, struct netlink_callback *cb) +{ + enum addr_type_t type = UNICAST_ADDR; + + return inet6_dump_addr(skb, cb, type, RTM_GETADDR2); } static int inet6_dump_ifmcaddr(struct sk_buff *skb, struct netlink_callback *cb) { enum addr_type_t type = MULTICAST_ADDR; - return inet6_dump_addr(skb, cb, type); + return inet6_dump_addr(skb, cb, type, RTM_GETMULTICAST); } @@ -5083,7 +5096,7 @@ static int inet6_dump_ifacaddr(struct sk_buff *skb, struct netlink_callback *cb) { enum addr_type_t type = ANYCAST_ADDR; - return inet6_dump_addr(skb, cb, type); + return inet6_dump_addr(skb, cb, type, RTM_GETANYCAST); } static int inet6_rtm_getaddr(struct sk_buff *in_skb, struct nlmsghdr *nlh, @@ -6833,6 +6846,11 @@ int __init addrconf_init(void) RTNL_FLAG_DOIT_UNLOCKED); if (err < 0) goto errout; + err = rtnl_register_module(THIS_MODULE, PF_INET6, RTM_GETADDR2, + inet6_rtm_getaddr, inet6_dump_ifaddr2, + RTNL_FLAG_DOIT_UNLOCKED); + if (err < 0) + goto errout; err = rtnl_register_module(THIS_MODULE, PF_INET6, RTM_GETMULTICAST, NULL, inet6_dump_ifmcaddr, 0); if (err < 0) From patchwork Thu Sep 27 17:58:54 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 975840 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=brauner.io Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=brauner.io header.i=@brauner.io header.b="GnMpJu2a"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 42LjHy3wM9z9sCW for ; Fri, 28 Sep 2018 03:59:42 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728632AbeI1ATF (ORCPT ); Thu, 27 Sep 2018 20:19:05 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:38419 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728525AbeI1ATE (ORCPT ); Thu, 27 Sep 2018 20:19:04 -0400 Received: by mail-ed1-f67.google.com with SMTP id x8-v6so5867857eds.5 for ; Thu, 27 Sep 2018 10:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=N3HBINMsThJvaGsXZVmuviY1doyzzZiK7DaUmpkTdJg=; b=GnMpJu2azb+KThJX8c21RCJcJM4B1JfDRQYbRGqxFCmZdHFXOqkHCZ7fqqHjoAjDjW MXYFh7dFwtw9vBheSjLxte67PPkWclnCmgMkg6geqQa646JheT+eCHnnP/4y5JnnccSA WdwpqYihiCXzPxmYw72G6PXsIATFfkTALILkPloL1Z7y7mbdMqfJq4ZFHDgf1j57/y5M Nia/s5j8+/CkXm9nHWCvs6VcctTAqBrDnkw5lHjVlPtqtTDErprJREMfWY4pcX53PCSW tKuQUypEc5/sTCrS72bj0dxZkTZp+EzLuxEkCKdQHL1ku7j0KLhBWO9CX1jP8fq3qd92 Fjdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=N3HBINMsThJvaGsXZVmuviY1doyzzZiK7DaUmpkTdJg=; b=CLS/ZWBLgPD51jpKWuIAK+fOTTN7et9b1DIaXqGGxVzEooDsRLnVEEGgBRb3qZE081 7uOVTvyGpXG3K7ik0WIKAx/U7f5P7cnIEuASBb28Y03Ya4VqpcEak9FD0DdYB5ZchZwB GgBz+sO8xNpP2KHgScha84m3sc3raLeVaVkrdh0mB6sdX35L1WhF+dQi352lnfF6PNJJ w0SK1bVPOVGaMj6nBS04rLXzxZygiE7BdcWXv+5gYafbP4e6SU51433O8nnt9vL/+lvK D30flm34uEGDz+f2U1efcsVT3GAfWcGya3XmjhHtSXQA7kvZMiKPyPquQ2zOiHlZ1611 SmEw== X-Gm-Message-State: ABuFfojnzxQ8Hkts1Ee4KY5wcgLYhbBPMRJqL8khcbfKbOMOzmbQo196 sELEHge3zonVheywGsXqTV/z2A== X-Google-Smtp-Source: ACcGV63/DU5jGBVX4lkJfJn98sNJkGkCEXWVLKy70GniZcMXdX2jeXwwWK8QcHjo2ZlZHtvngKqwwQ== X-Received: by 2002:a50:a705:: with SMTP id h5-v6mr19831560edc.162.1538071176974; Thu, 27 Sep 2018 10:59:36 -0700 (PDT) Received: from localhost.localdomain (fa-padur-binz.ediscom.de. [212.204.40.18]) by smtp.gmail.com with ESMTPSA id a9-v6sm1532606edi.26.2018.09.27.10.59.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 10:59:36 -0700 (PDT) From: Christian Brauner To: jbenc@redhat.com, davem@davemloft.net, dsahern@gmail.com, stephen@networkplumber.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Christian Brauner Subject: [PATCH net-next 4/7] decnet: add RTM_GETADDR2 Date: Thu, 27 Sep 2018 19:58:54 +0200 Message-Id: <20180927175857.3511-5-christian@brauner.io> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180927175857.3511-1-christian@brauner.io> References: <20180927175857.3511-1-christian@brauner.io> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Various userspace programs (e.g. iproute2) have sent RTM_GETADDR requests with struct ifinfomsg. This is wrong and should have been struct ifaddrmsg all along as mandated by the manpages. However, dump requests so far didn't parse the netlink message that was sent and succeeded even when a wrong struct was passed along. Currently, the message is parsed under the assumption that the correct struct ifaddrmsg is sent down. If the parsing fails the kernel will still fulfill the request to preserve backwards compatability but a rate-limited message that there were leftover bytes after parsing the message is recorded in dmesg. It has been argued that this is unacceptable [1]. But various new features that got and will get added to RTM_GETADDR make it necessary to definitely know what header was passed along. This is currently not possible without resorting to (likely unreliable) hacks such as introducing a nested attribute that ensures that RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID always exceed RTM_GETADDR requests that send down the wrong struct ifinfomsg [2]. Basically, multiple approaches to solve this have been shut down. Furthermore, the API expressed via RTM_GETADDR is apparently frozen [3] so the wiggle room at this point seems very much zero. The correct solution at this point seems to me to introduce a new RTM_GETADDR2 request. This way we can parse the message and fail hard if the struct is not struct ifaddrmsg and can safely extend it in the future. Userspace tools that rely on the buggy RTM_GETADDR API will still keep working without even having to see any log messages and new userspace tools that want to make user of new features can make use of the new RTM_GETADDR2 requests. [1]: https://lists.openwall.net/netdev/2018/09/25/59 [2]: https://lists.openwall.net/netdev/2018/09/25/75 [3]: https://lists.openwall.net/netdev/2018/09/26/166 Signed-off-by: Christian Brauner Cc: David Ahern Cc: Jiri Benc Cc: Stephen Hemminger --- net/decnet/dn_dev.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/net/decnet/dn_dev.c b/net/decnet/dn_dev.c index d0b3e69c6b39..8da6ca154c08 100644 --- a/net/decnet/dn_dev.c +++ b/net/decnet/dn_dev.c @@ -738,10 +738,12 @@ static void dn_ifaddr_notify(int event, struct dn_ifaddr *ifa) rtnl_set_sk_err(&init_net, RTNLGRP_DECnet_IFADDR, err); } -static int dn_nl_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) +static int dn_nl_dump_ifaddr_common(struct sk_buff *skb, + struct netlink_callback *cb, int rtm_type) { struct net *net = sock_net(skb->sk); - int idx, dn_idx = 0, skip_ndevs, skip_naddr; + int err, idx, dn_idx = 0, skip_ndevs, skip_naddr; + struct nlattr *tb[IFA_MAX+1]; struct net_device *dev; struct dn_dev *dn_db; struct dn_ifaddr *ifa; @@ -749,6 +751,13 @@ static int dn_nl_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) if (!net_eq(net, &init_net)) return 0; + if (rtm_type == RTM_GETADDR2) { + err = nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, IFA_MAX, + dn_ifa_policy, NULL); + if (err < 0) + return err; + } + skip_ndevs = cb->args[0]; skip_naddr = cb->args[1]; @@ -787,6 +796,16 @@ static int dn_nl_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) return skb->len; } +static int dn_nl_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) +{ + return dn_nl_dump_ifaddr_common(skb, cb, RTM_GETADDR); +} + +static int dn_nl_dump_ifaddr2(struct sk_buff *skb, struct netlink_callback *cb) +{ + return dn_nl_dump_ifaddr_common(skb, cb, RTM_GETADDR2); +} + static int dn_dev_get_first(struct net_device *dev, __le16 *addr) { struct dn_dev *dn_db; @@ -1410,6 +1429,8 @@ void __init dn_dev_init(void) dn_nl_deladdr, NULL, 0); rtnl_register_module(THIS_MODULE, PF_DECnet, RTM_GETADDR, NULL, dn_nl_dump_ifaddr, 0); + rtnl_register_module(THIS_MODULE, PF_DECnet, RTM_GETADDR2, + NULL, dn_nl_dump_ifaddr2, 0); proc_create_seq("decnet_dev", 0444, init_net.proc_net, &dn_dev_seq_ops); From patchwork Thu Sep 27 17:58:55 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 975843 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=brauner.io Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=brauner.io header.i=@brauner.io header.b="CyEIEhW3"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 42LjJJ1jFlz9s1x for ; Fri, 28 Sep 2018 04:00:00 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728651AbeI1ATI (ORCPT ); Thu, 27 Sep 2018 20:19:08 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:34585 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727599AbeI1ATG (ORCPT ); Thu, 27 Sep 2018 20:19:06 -0400 Received: by mail-ed1-f65.google.com with SMTP id q19-v6so5888320edr.1 for ; Thu, 27 Sep 2018 10:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=YmXqigRf7MfAJWZebhXsQvKzthN4owk6/gKa5Zoooq0=; b=CyEIEhW3dT+9ySGJeYFgzZtQ5alkC47y8dUzfcXK8YkWal3m10U3JQVmSMzVNBmg+A zFiOhPRUkQZWc+PZcc2gWJm1f9Jh8Npa5ffqtt5SVrhcy65GXEaFZyq2dKYcoa51HXLu uAyPyIWrSUamLgSolJtHjrKWHTFXhALFCLfuB8cpjYpMKDEohBTY7xVpiinWib9z+3GC 4+S53gXtw3pepZEn3Zkr9OPczKxtUwH3XfuIHRnAV53sT/BnkcZ8YqGWFdYWswsOTOaI WRh4UFM6GkRbJlcg423TaNnHaHE4rqcsbGviczbWFKe9X/IwN6Xy4LJ+tLgL0QNCcEdb d9hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=YmXqigRf7MfAJWZebhXsQvKzthN4owk6/gKa5Zoooq0=; b=CJaoBu5aMqsipmlhWOKpJKO9OYCrMV/JdXTLfkltPb4QgqJddn9HAoFXxl/LPjZDhy kKEyUlejMfAU+4Jun4exP/EIPqBF9gqzJ4mgGS518w2zj66AGonB3VGu0QKO2F3qyWLu d4xUI/Vdr4IayTfC9mqL+og3iMDrHTENN5ZdQPF1VoxbJETCIOZzgoZr6liNmjDw2O2M x/OpygJpgxjuVHkMlI4OJ4Ux0l4Qux/Pf9MVnglnT8W4zVG/CU8WAI2fk6XW54qBvhC9 S1daDQ8+wma+e5x+b8HhO9vDXO66YnYJs+gHeDGf5LCBNGcrULO3MPGf6UrUKHObORlA CzGw== X-Gm-Message-State: ABuFfoisfrSHzsB0T09Wz2pEvKsFdrWaoYCz2ihTmwjOZQAs9gSVi+eA L+B9gFYx4er4NtRW7X3n045UaQ== X-Google-Smtp-Source: ACcGV62gr2+Olm8NzrDZqC07NtlAPorXCWBmiGr/u3JnM1ybFnPfARmz+f2bSG/dGYVP7f7fI2CrsA== X-Received: by 2002:a17:906:619a:: with SMTP id q26-v6mr2888167ejk.127.1538071178879; Thu, 27 Sep 2018 10:59:38 -0700 (PDT) Received: from localhost.localdomain (fa-padur-binz.ediscom.de. [212.204.40.18]) by smtp.gmail.com with ESMTPSA id a9-v6sm1532606edi.26.2018.09.27.10.59.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 10:59:37 -0700 (PDT) From: Christian Brauner To: jbenc@redhat.com, davem@davemloft.net, dsahern@gmail.com, stephen@networkplumber.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Christian Brauner Subject: [PATCH net-next 5/7] phonet: add RTM_GETADDR2 Date: Thu, 27 Sep 2018 19:58:55 +0200 Message-Id: <20180927175857.3511-6-christian@brauner.io> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180927175857.3511-1-christian@brauner.io> References: <20180927175857.3511-1-christian@brauner.io> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Various userspace programs (e.g. iproute2) have sent RTM_GETADDR requests with struct ifinfomsg. This is wrong and should have been struct ifaddrmsg all along as mandated by the manpages. However, dump requests so far didn't parse the netlink message that was sent and succeeded even when a wrong struct was passed along. Currently, the message is parsed under the assumption that the correct struct ifaddrmsg is sent down. If the parsing fails the kernel will still fulfill the request to preserve backwards compatability but a rate-limited message that there were leftover bytes after parsing the message is recorded in dmesg. It has been argued that this is unacceptable [1]. But various new features that got and will get added to RTM_GETADDR make it necessary to definitely know what header was passed along. This is currently not possible without resorting to (likely unreliable) hacks such as introducing a nested attribute that ensures that RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID always exceed RTM_GETADDR requests that send down the wrong struct ifinfomsg [2]. Basically, multiple approaches to solve this have been shut down. Furthermore, the API expressed via RTM_GETADDR is apparently frozen [3] so the wiggle room at this point seems very much zero. The correct solution at this point seems to me to introduce a new RTM_GETADDR2 request. This way we can parse the message and fail hard if the struct is not struct ifaddrmsg and can safely extend it in the future. Userspace tools that rely on the buggy RTM_GETADDR API will still keep working without even having to see any log messages and new userspace tools that want to make user of new features can make use of the new RTM_GETADDR2 requests. [1]: https://lists.openwall.net/netdev/2018/09/25/59 [2]: https://lists.openwall.net/netdev/2018/09/25/75 [3]: https://lists.openwall.net/netdev/2018/09/26/166 Signed-off-by: Christian Brauner Cc: David Ahern Cc: Jiri Benc Cc: Stephen Hemminger --- net/phonet/pn_netlink.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/net/phonet/pn_netlink.c b/net/phonet/pn_netlink.c index 871eaf2cb85e..acba4fe9a612 100644 --- a/net/phonet/pn_netlink.c +++ b/net/phonet/pn_netlink.c @@ -131,13 +131,22 @@ static int fill_addr(struct sk_buff *skb, struct net_device *dev, u8 addr, return -EMSGSIZE; } -static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb) +static int getaddr_dumpit_common(struct sk_buff *skb, + struct netlink_callback *cb, int rtm_type) { struct phonet_device_list *pndevs; + struct nlattr *tb[IFA_MAX+1]; struct phonet_device *pnd; - int dev_idx = 0, dev_start_idx = cb->args[0]; + int err, dev_idx = 0, dev_start_idx = cb->args[0]; int addr_idx = 0, addr_start_idx = cb->args[1]; + if (rtm_type == RTM_GETADDR2) { + err = nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, + IFA_MAX, ifa_phonet_policy, NULL); + if (err < 0) + return err; + } + pndevs = phonet_device_list(sock_net(skb->sk)); rcu_read_lock(); list_for_each_entry_rcu(pnd, &pndevs->list, list) { @@ -168,6 +177,16 @@ static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb) return skb->len; } +static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb) +{ + return getaddr_dumpit_common(skb, cb, RTM_GETADDR); +} + +static int getaddr_dumpit2(struct sk_buff *skb, struct netlink_callback *cb) +{ + return getaddr_dumpit_common(skb, cb, RTM_GETADDR2); +} + /* Routes handling */ static int fill_route(struct sk_buff *skb, struct net_device *dev, u8 dst, @@ -309,6 +328,8 @@ int __init phonet_netlink_register(void) addr_doit, NULL, 0); rtnl_register_module(THIS_MODULE, PF_PHONET, RTM_GETADDR, NULL, getaddr_dumpit, 0); + rtnl_register_module(THIS_MODULE, PF_PHONET, RTM_GETADDR2, + NULL, getaddr_dumpit2, 0); rtnl_register_module(THIS_MODULE, PF_PHONET, RTM_NEWROUTE, route_doit, NULL, 0); rtnl_register_module(THIS_MODULE, PF_PHONET, RTM_DELROUTE, From patchwork Thu Sep 27 17:58:56 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 975842 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=brauner.io Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=brauner.io header.i=@brauner.io header.b="XOMZme7/"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 42LjJG225tz9s3Z for ; Fri, 28 Sep 2018 03:59:58 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728698AbeI1ATV (ORCPT ); Thu, 27 Sep 2018 20:19:21 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:42911 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728370AbeI1ATI (ORCPT ); Thu, 27 Sep 2018 20:19:08 -0400 Received: by mail-ed1-f68.google.com with SMTP id b20-v6so5848868edr.9 for ; Thu, 27 Sep 2018 10:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=//4teGx2aqB1iUXfxLOI165v5hE2Bibr4eSEPlWj71c=; b=XOMZme7/dlhYD9c/JGgN8lf+xDfuBQg4hBTpysq0HK9md5iUCSwkbdg/GapnQXjuVp 3xouYNlX7OclL0IW2gj9EUYWaMQp27c/9+5QrsyRGLxdPm1j75X2WWWGlHSToWdRAZAf Cjr26NjtTerlXq/Dabkxxj4YfyWsY2Q/BXpKrgDu28zscavCfBmfXJsdLYeQk0yma2I9 p7ujkZHLUucmOmK6DDsrKTWPOmFQrt4ebS/SxT333kUk9f4t4uSW83vi18+O24X0WlUY PQX6eUkqrklF2nyoAE7XrboSUaw3vWP8yLD1mYHMExzV2vSGz+7uC8q5RTs/DVjt2xGE 8jig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=//4teGx2aqB1iUXfxLOI165v5hE2Bibr4eSEPlWj71c=; b=OgYTBa5nJ8ONp4NrfkFwyMmfKnVpY5WLY48Z5fLwN41PYCz3pCcRfMRON13yEkAx63 xNkISzRe+izQhfqMa51jdBAFb/rV+6aum3iOlEDYlCH1niOXHcD4NAIdKNdzeuzwWQFa x89g07P6p/7qhwIiQah4t2IX++jL2el/mb7xzY7hQOL2JRakaHEnd3bHcbuZ37h6jJnS W10MfdOR7bVxO01XNZYv02z4cqbuwBK1Nk+KlNprCjpZsvY1z6YMZ+nyrVFk9dhMUtZe 7El9yqlyvNpeCCTRAFSRRseD+E0zIZqJ942Pxm6/ZEUapBjKq14g/YVLe6eug3VxYHGK ZXbQ== X-Gm-Message-State: ABuFfoh3G2KGgJfrPGf1wgrhV8hwbmjT2KaYioW6KM7ej1BqGlj0lWfX /p/feA89mexSzc5WXpVjVgg+fg== X-Google-Smtp-Source: ACcGV62CBa6SJDpxAssNKPxLwsEU/SaMug/DJvUnAkKu/ojW5sDCWnmkyB/6psBY2qSEKYy76F++DQ== X-Received: by 2002:a50:c2c9:: with SMTP id u9-v6mr9852227edf.15.1538071180843; Thu, 27 Sep 2018 10:59:40 -0700 (PDT) Received: from localhost.localdomain (fa-padur-binz.ediscom.de. [212.204.40.18]) by smtp.gmail.com with ESMTPSA id a9-v6sm1532606edi.26.2018.09.27.10.59.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 10:59:39 -0700 (PDT) From: Christian Brauner To: jbenc@redhat.com, davem@davemloft.net, dsahern@gmail.com, stephen@networkplumber.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Christian Brauner Subject: [PATCH net-next 6/7] selinux: add RTM_GETADDR2 Date: Thu, 27 Sep 2018 19:58:56 +0200 Message-Id: <20180927175857.3511-7-christian@brauner.io> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180927175857.3511-1-christian@brauner.io> References: <20180927175857.3511-1-christian@brauner.io> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Various userspace programs (e.g. iproute2) have sent RTM_GETADDR requests with struct ifinfomsg. This is wrong and should have been struct ifaddrmsg all along as mandated by the manpages. However, dump requests so far didn't parse the netlink message that was sent and succeeded even when a wrong struct was passed along. Currently, the message is parsed under the assumption that the correct struct ifaddrmsg is sent down. If the parsing fails the kernel will still fulfill the request to preserve backwards compatability but a rate-limited message that there were leftover bytes after parsing the message is recorded in dmesg. It has been argued that this is unacceptable [1]. But various new features that got and will get added to RTM_GETADDR make it necessary to definitely know what header was passed along. This is currently not possible without resorting to (likely unreliable) hacks such as introducing a nested attribute that ensures that RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID always exceed RTM_GETADDR requests that send down the wrong struct ifinfomsg [2]. Basically, multiple approaches to solve this have been shut down. Furthermore, the API expressed via RTM_GETADDR is apparently frozen [3] so the wiggle room at this point seems very much zero. The correct solution at this point seems to me to introduce a new RTM_GETADDR2 request. This way we can parse the message and fail hard if the struct is not struct ifaddrmsg and can safely extend it in the future. Userspace tools that rely on the buggy RTM_GETADDR API will still keep working without even having to see any log messages and new userspace tools that want to make user of new features can make use of the new RTM_GETADDR2 requests. [1]: https://lists.openwall.net/netdev/2018/09/25/59 [2]: https://lists.openwall.net/netdev/2018/09/25/75 [3]: https://lists.openwall.net/netdev/2018/09/26/166 Signed-off-by: Christian Brauner Cc: David Ahern Cc: Jiri Benc Cc: Stephen Hemminger --- security/selinux/nlmsgtab.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/security/selinux/nlmsgtab.c b/security/selinux/nlmsgtab.c index 74b951f55608..3c45f50e987d 100644 --- a/security/selinux/nlmsgtab.c +++ b/security/selinux/nlmsgtab.c @@ -80,6 +80,7 @@ static const struct nlmsg_perm nlmsg_route_perms[] = { RTM_NEWSTATS, NETLINK_ROUTE_SOCKET__NLMSG_READ }, { RTM_GETSTATS, NETLINK_ROUTE_SOCKET__NLMSG_READ }, { RTM_NEWCACHEREPORT, NETLINK_ROUTE_SOCKET__NLMSG_READ }, + { RTM_GETADDR2, NETLINK_ROUTE_SOCKET__NLMSG_READ }, }; static const struct nlmsg_perm nlmsg_tcpdiag_perms[] = @@ -159,7 +160,7 @@ int selinux_nlmsg_lookup(u16 sclass, u16 nlmsg_type, u32 *perm) switch (sclass) { case SECCLASS_NETLINK_ROUTE_SOCKET: /* RTM_MAX always point to RTM_SETxxxx, ie RTM_NEWxxx + 3 */ - BUILD_BUG_ON(RTM_MAX != (RTM_NEWCHAIN + 3)); + BUILD_BUG_ON(RTM_MAX != (RTM_GETADDR2 + 1)); err = nlmsg_perm(nlmsg_type, perm, nlmsg_route_perms, sizeof(nlmsg_route_perms)); break; From patchwork Thu Sep 27 17:58:57 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 975841 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=brauner.io Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; secure) header.d=brauner.io header.i=@brauner.io header.b="TyGovieV"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 42LjJ70g5fz9s1x for ; Fri, 28 Sep 2018 03:59:51 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728680AbeI1ATK (ORCPT ); Thu, 27 Sep 2018 20:19:10 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:45355 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728623AbeI1ATJ (ORCPT ); Thu, 27 Sep 2018 20:19:09 -0400 Received: by mail-ed1-f67.google.com with SMTP id h6-v6so4378390eds.12 for ; Thu, 27 Sep 2018 10:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=arazljuNqXrVl7csMU1Hah8nOZ2HJXqpSiK6JCvosbY=; b=TyGovieVXCWeibJxznT15RBYZXciuCeCKP290ehBD+z09UYdNy7G77Y62Z3YKSdxUE +xvYuiy3VlgYATIjCP4WelLcJJzcrHcvQ4KyTuxxFgbfsTAVkMF09tkIp3RYEG5ic2tJ G53fDJei4oSiqNnLtDwnL3BWKMT22+FCWYd4OTLYD6MUoPTNv+dirdJKOiXe7pktlmYZ 0DuIlu/CgVP5vFpAV6NdVu2kpONlJSVTggwgqLTEPBft1FVS0rfp9RDWyS5CNMnBpLW4 1DbhmOJRzT1HeUMLYxupVowTotFMaJkQYUPwJCDJ8oc21YLdiLqQzc94G2crknse8MEa WCSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=arazljuNqXrVl7csMU1Hah8nOZ2HJXqpSiK6JCvosbY=; b=m0mtugw6xfL4zIMapkfwLVrYIQbZ6LszxSb4kC4mGx0TQuHvs63R/LkV7yE5K2up1D bBLxNoAeECdAm8PU05NUJZHibVgXaesA9ixFO8pZmr7SGrMilNfpuPu0WoJz8yJlUOQm PQU6OvvRiQJ9Bd2+RBFOkmGCKku6x1V+8aHhpHdDBGeZUuSh3ImyRcxXLF0E9uB6VoUi Zld+L0Yy7Iy53IbnVvl5HwVXIJtOycgu13fFc+boJ2iHK+1nt+1UUbw4BJ/aalKwgKBY hIIZ9a+iIio8olwwb0zzrVwU7PEvstz43P4IeTqvFW7p72t0OqxsU5bbUd/n6AfKTuLL d1hQ== X-Gm-Message-State: ABuFfoj/UDJLeqbHUQ75ISIUWaCKO+oVqRw8ExnQTR6/VIIM/AG0AGy/ 5XUlzA7yTRI2/QQejjFZu1ir/g== X-Google-Smtp-Source: ACcGV62hgH6i+r9RZeXkSXR3xD1QeYcsx8Alz9XHVVLN2HZuRtIaS4zQELlqQhO5urvtS01MAdFUug== X-Received: by 2002:a05:6402:884:: with SMTP id e4mr20104001edy.1.1538071182326; Thu, 27 Sep 2018 10:59:42 -0700 (PDT) Received: from localhost.localdomain (fa-padur-binz.ediscom.de. [212.204.40.18]) by smtp.gmail.com with ESMTPSA id a9-v6sm1532606edi.26.2018.09.27.10.59.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 10:59:41 -0700 (PDT) From: Christian Brauner To: jbenc@redhat.com, davem@davemloft.net, dsahern@gmail.com, stephen@networkplumber.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Christian Brauner Subject: [PATCH net-next 7/7] rtnetlink: enable RTM_GETADDR2 Date: Thu, 27 Sep 2018 19:58:57 +0200 Message-Id: <20180927175857.3511-8-christian@brauner.io> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180927175857.3511-1-christian@brauner.io> References: <20180927175857.3511-1-christian@brauner.io> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Various userspace programs (e.g. iproute2) have sent RTM_GETADDR requests with struct ifinfomsg. This is wrong and should have been struct ifaddrmsg all along as mandated by the manpages. However, dump requests so far didn't parse the netlink message that was sent and succeeded even when a wrong struct was passed along. Currently, the message is parsed under the assumption that the correct struct ifaddrmsg is sent down. If the parsing fails the kernel will still fulfill the request to preserve backwards compatability but a rate-limited message that there were leftover bytes after parsing the message is recorded in dmesg. It has been argued that this is unacceptable [1]. But various new features that got and will get added to RTM_GETADDR make it necessary to definitely know what header was passed along. This is currently not possible without resorting to (likely unreliable) hacks such as introducing a nested attribute that ensures that RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID always exceed RTM_GETADDR requests that send down the wrong struct ifinfomsg [2]. Basically, multiple approaches to solve this have been shut down. Furthermore, the API expressed via RTM_GETADDR is apparently frozen [3] so the wiggle room at this point seems very much zero. The correct solution at this point seems to me to introduce a new RTM_GETADDR2 request. This way we can parse the message and fail hard if the struct is not struct ifaddrmsg and can safely extend it in the future. Userspace tools that rely on the buggy RTM_GETADDR API will still keep working without even having to see any log messages and new userspace tools that want to make user of new features can make use of the new RTM_GETADDR2 requests. [1]: https://lists.openwall.net/netdev/2018/09/25/59 [2]: https://lists.openwall.net/netdev/2018/09/25/75 [3]: https://lists.openwall.net/netdev/2018/09/26/166 Signed-off-by: Christian Brauner Cc: David Ahern Cc: Jiri Benc Cc: Stephen Hemminger --- net/core/rtnetlink.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index 35162e1b06ad..2ec020236053 100644 --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -4835,6 +4835,7 @@ void __init rtnetlink_init(void) rtnl_register(PF_UNSPEC, RTM_DELLINK, rtnl_dellink, NULL, 0); rtnl_register(PF_UNSPEC, RTM_GETADDR, NULL, rtnl_dump_all, 0); + rtnl_register(PF_UNSPEC, RTM_GETADDR2, NULL, rtnl_dump_all, 0); rtnl_register(PF_UNSPEC, RTM_GETROUTE, NULL, rtnl_dump_all, 0); rtnl_register(PF_UNSPEC, RTM_GETNETCONF, NULL, rtnl_dump_all, 0);