From patchwork Tue Sep 12 03:16:30 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Khalid Elmously X-Patchwork-Id: 1832614 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=Gs3Wi5e2; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=185.125.189.65; helo=lists.ubuntu.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=patchwork.ozlabs.org) Received: from lists.ubuntu.com (lists.ubuntu.com [185.125.189.65]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4Rl8183s3gz1yhm for ; Tue, 12 Sep 2023 13:18:20 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=lists.ubuntu.com) by lists.ubuntu.com with esmtp (Exim 4.86_2) (envelope-from ) id 1qftue-0007GS-86; Tue, 12 Sep 2023 03:18:04 +0000 Received: from smtp-relay-internal-0.internal ([10.131.114.225] helo=smtp-relay-internal-0.canonical.com) by lists.ubuntu.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1qftub-0007Fc-F0 for kernel-team@lists.ubuntu.com; Tue, 12 Sep 2023 03:18:01 +0000 Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 2CAFA3F314 for ; Tue, 12 Sep 2023 03:18:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1694488681; bh=LLJpNJX8Y2HHZpymY1+E1YZEjrLMKPEEW0R/yGTTev0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Gs3Wi5e2MH6Nn5NvC6crxn8rJ1s0Uq3cLaVSma/ObuBaFFG6WStdVXx9HkqOUG2HO qdnXX9Q+Am8CVC9B/Ny5HYXXI1qABpc6yAsmmrd21BfwAH5Je9Vwxa/tzvSTiPpupn lHL4Ii5bRKIHOkffgwFFVYVK0CXuAQGt7SqfPEo4si/viljnljf/tehwqLEgHLOp/4 0KwQ6mprk2I3R56hlzbPF0Irebuq/M4OGiOeHRa3xBEp8BuhIotN9DzgngHRETbEhe 57u9J7yVgQlizh90LHu23lg8MilItlurCAx2UtVfCfpAaYV0rz/OTg+xj5j8FxO5aq Sn9l6detzWHEQ== Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-411f95b1a31so53139641cf.1 for ; Mon, 11 Sep 2023 20:18:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694488680; x=1695093480; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LLJpNJX8Y2HHZpymY1+E1YZEjrLMKPEEW0R/yGTTev0=; b=E/GBEsguoJp+j1dZyFhM1NGdSznXIbiUIGE5wgtJcCiFpXRLAkwPk7DHN10pUjqQur Lxhv910V5jm4sOUmyxe+7S4oaMOZEme+bs2o/HOoowANbx+CADGeDu+6y64Sjemgabyr 4GAThndY2tuv++DO9k8oVpJJbg7Mx1VEvtJJ8zh8sK6/Zt9it+4LQgvkXtcqbqvnIokt XS0YjeGHusBYM9ZZLHcihDr+4TZbIZiHzMYoW5IJC6dF1IWRuGNMUdkDeIekdh2NQdYj Y+QHdbIvKqPoTtPI5PqevjJZg6hl0s5snj96G9n15D5JW9HSv+RWgAtvJq1m0AHq1QgH POog== X-Gm-Message-State: AOJu0YwGLo1K1tqTKvoRGA8vHBgkTCbUyUgS+GQ7Bcxs03HpT/RQc3CM Xy+Vm9YTuksi6GHhNKBG2lHaJHLlRY7goVolla4m20WfJBzJvFuZWhw72OelgxrZIPuSpIe0rd0 LSU1l1QOEyq5SVuHYLI9xIbupcOmmjFu7/e2anqzF2TP8hVWhpfFi X-Received: by 2002:a05:622a:1d4:b0:403:edd0:8a4c with SMTP id t20-20020a05622a01d400b00403edd08a4cmr13351093qtw.23.1694488680012; Mon, 11 Sep 2023 20:18:00 -0700 (PDT) X-Google-Smtp-Source: AGHT+IErAm6h5UHF/18+xRPmPyiHH2yptL4kzmrzWGeveNfeIv1ZT07qu8a50UMKjH65ssfWC2ONiQ== X-Received: by 2002:a05:622a:1d4:b0:403:edd0:8a4c with SMTP id t20-20020a05622a01d400b00403edd08a4cmr13351083qtw.23.1694488679769; Mon, 11 Sep 2023 20:17:59 -0700 (PDT) Received: from k2.fuzzbuzz.org ([38.147.253.170]) by smtp.gmail.com with ESMTPSA id l1-20020ac87241000000b00410957eaf3csm3003275qtp.21.2023.09.11.20.17.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Sep 2023 20:17:59 -0700 (PDT) From: Khalid Elmously To: kernel-team@lists.ubuntu.com Subject: [PATCH 1/1] net: Avoid address overwrite in kernel_connect Date: Mon, 11 Sep 2023 23:16:30 -0400 Message-Id: <20230912031630.678178-2-khalid.elmously@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230912031630.678178-1-khalid.elmously@canonical.com> References: <20230912031630.678178-1-khalid.elmously@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Jordan Rife BugLink: https://bugs.launchpad.net/bugs/2035163 BPF programs that run on connect can rewrite the connect address. For the connect system call this isn't a problem, because a copy of the address is made when it is moved into kernel space. However, kernel_connect simply passes through the address it is given, so the caller may observe its address value unexpectedly change. A practical example where this is problematic is where NFS is combined with a system such as Cilium which implements BPF-based load balancing. A common pattern in software-defined storage systems is to have an NFS mount that connects to a persistent virtual IP which in turn maps to an ephemeral server IP. This is usually done to achieve high availability: if your server goes down you can quickly spin up a replacement and remap the virtual IP to that endpoint. With BPF-based load balancing, mounts will forget the virtual IP address when the address rewrite occurs because a pointer to the only copy of that address is passed down the stack. Server failover then breaks, because clients have forgotten the virtual IP address. Reconnects fail and mounts remain broken. This patch was tested by setting up a scenario like this and ensuring that NFS reconnects worked after applying the patch. Signed-off-by: Jordan Rife Signed-off-by: David S. Miller (backported from commit 0bdf399342c5acbd817c9098b6c7ed21f1974312) [ kmously: adjusted for lack of READ_ONCE() ] Signed-off-by: Khalid Elmously --- net/socket.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/socket.c b/net/socket.c index 5c49074ef7f2ae..7344dcc7cb1ccb 100644 --- a/net/socket.c +++ b/net/socket.c @@ -3453,7 +3453,12 @@ EXPORT_SYMBOL(kernel_accept); int kernel_connect(struct socket *sock, struct sockaddr *addr, int addrlen, int flags) { - return sock->ops->connect(sock, addr, addrlen, flags); + struct sockaddr_storage address; + + memcpy(&address, addr, addrlen); + + return sock->ops->connect(sock, (struct sockaddr *)&address, + addrlen, flags); } EXPORT_SYMBOL(kernel_connect);