Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1776724pxb; Mon, 8 Mar 2021 06:13:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJz9oEBEJA+NrDhIHc1FHLk81P0Zd+FSlTMxl5AycwSdvOewAfUfHSyyYG1jvwWTuV/+LiK8 X-Received: by 2002:a17:907:9862:: with SMTP id ko2mr14895775ejc.222.1615212829528; Mon, 08 Mar 2021 06:13:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615212829; cv=none; d=google.com; s=arc-20160816; b=pBHmoeeZ8rCIzR2NLQVJShqZG+BUsaIPdW4lTramtwkWEHgPDX4eiRyGuYYseVAFRd A1F+ooMTYUla4E1A6Oi7bPNKA3tOtZ6fur/x1Rniz6DegSRiRyp/nGJaGvugSv/AgnIv 8gRqeKeTyeLs1EOLOeuhVqvK9g9FarIgBpJm1E3QHogLTb10gXaegVeo2u6rexr0m1Al AIq+KIm43U4JTPQlpufrpzZrNRNTIDMmpLQTXgxUCVE813Ypn/06S/hfL/Xgho7KHTOY MlHFuzU5nznWuNkULsJ0h6KSLPtm1OPoaJkdLhw7HSDIg4nY1lUKG66pve6GeMOCz2ac M7bQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=hL49nTVoKzEWo2s94XqcXwbYov04tX+0cqwzgG9H3LY=; b=uLtvXtr4F09igcl0eFEgTcfQ2NEsFe097COxtNMj8kLdPgXKR9HbkTMw55Jw5NJ/BL 6JarT/hzcOJakmzR9vnNzT0ulj95UGDLngWAT6a4oBIbKT9Ymw0Nvp8jvsWFTa2Xezoy s65LZBK4t5vSTbyP4pE1Rt1qhyUVqUWZwA4FbE0RAKBwDpQdD9g9gRdtrlT4ZN4J7swW l/lkMI22oSupmP4imTa5MTCAYTjXkdxDWC5ciJjikHoA9o1fXesNiXQ/d7LoJi25QdSu fn+LfYUQ3v+Vsy/BRv2toTm86gY1VxxLlrC0xWo42eu2ZU0xzJOC4H88crASINsuRn7K R2Ig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=LMqKuem1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bl4si7203885ejb.47.2021.03.08.06.13.26; Mon, 08 Mar 2021 06:13:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=LMqKuem1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231195AbhCHOMY (ORCPT + 99 others); Mon, 8 Mar 2021 09:12:24 -0500 Received: from mail.kernel.org ([198.145.29.99]:39884 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231184AbhCHOLy (ORCPT ); Mon, 8 Mar 2021 09:11:54 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 80586650F2; Mon, 8 Mar 2021 14:11:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615212714; bh=7NQYViq1K/ArxZ0PMXgM0Mljqh1vleJSjOTVqm6z4SU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LMqKuem1vPWCxyhbPs5R71G600fCYN8q3kVVffh7HuPIYcB40JECDTJk9XRNJhYP/ WOIPMlAQZhGCe4JkO5k9XTmaB1KQnX4IYNDSOZ0vSIRXz5+kRwhRYuURuwG7Y8Mad9 BmIgiD81rtE4nAbJzRND5KuSPhbh2qNqVmWEJInM= Date: Mon, 8 Mar 2021 14:21:15 +0100 From: Greg Kroah-Hartman To: Pavel Machek Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, "Gong, Sishuai" , Eric Dumazet , Jakub Kicinski , Cong Wang , "David S. Miller" Subject: Re: [PATCH 5.10 031/102] net: fix dev_ifsioc_locked() race condition Message-ID: References: <20210305120903.276489876@linuxfoundation.org> <20210305120904.814003997@linuxfoundation.org> <20210308125057.GA19538@duo.ucw.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210308125057.GA19538@duo.ucw.cz> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 08, 2021 at 01:50:57PM +0100, Pavel Machek wrote: > Hi! > > > commit 3b23a32a63219f51a5298bc55a65ecee866e79d0 upstream. > > > > dev_ifsioc_locked() is called with only RCU read lock, so when > > there is a parallel writer changing the mac address, it could > > get a partially updated mac address, as shown below: > > > > Thread 1 Thread 2 > > // eth_commit_mac_addr_change() > > memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN); > > // dev_ifsioc_locked() > > memcpy(ifr->ifr_hwaddr.sa_data, > > dev->dev_addr,...); > > > > Close this race condition by guarding them with a RW semaphore, > > like netdev_get_name(). We can not use seqlock here as it does not > > I guess it may fix a race, but... does it leak kernel stack data to > userland? > > > > +++ b/drivers/net/tap.c > > @@ -1093,10 +1093,9 @@ static long tap_ioctl(struct file *file, > > return -ENOLINK; > > } > > ret = 0; > > - u = tap->dev->type; > > + dev_get_mac_address(&sa, dev_net(tap->dev), tap->dev->name); > > if (copy_to_user(&ifr->ifr_name, tap->dev->name, IFNAMSIZ) || > > - copy_to_user(&ifr->ifr_hwaddr.sa_data, tap->dev->dev_addr, ETH_ALEN) || > > - put_user(u, &ifr->ifr_hwaddr.sa_family)) > > + copy_to_user(&ifr->ifr_hwaddr, &sa, sizeof(sa))) > > ret = -EFAULT; > > tap_put_tap_dev(tap); > > rtnl_unlock(); > > We copy whole "struct sockaddr". > > > +int dev_get_mac_address(struct sockaddr *sa, struct net *net, char *dev_name) > > +{ > > + size_t size = sizeof(sa->sa_data); > > + struct net_device *dev; > > + int ret = 0; > ... > > + if (!dev->addr_len) > > + memset(sa->sa_data, 0, size); > > + else > > + memcpy(sa->sa_data, dev->dev_addr, > > + min_t(size_t, size, dev->addr_len)); > > But we only coppied dev->addr_len bytes in. > > This would be very simple way to plug the leak. > > Signed-off-by: Pavel Machek (CIP) > > diff --git a/net/core/dev.c b/net/core/dev.c > index 75ca6c6d01d6..b67ff23a1f0d 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -8714,11 +8714,9 @@ int dev_get_mac_address(struct sockaddr *sa, struct net *net, char *dev_name) > ret = -ENODEV; > goto unlock; > } > - if (!dev->addr_len) > - memset(sa->sa_data, 0, size); > - else > - memcpy(sa->sa_data, dev->dev_addr, > - min_t(size_t, size, dev->addr_len)); > + memset(sa->sa_data, 0, size); > + memcpy(sa->sa_data, dev->dev_addr, > + min_t(size_t, size, dev->addr_len)); > sa->sa_family = dev->type; > > unlock: > Please submit this change properly to the networking developers, they are not going to pick anything up this way. greg k-h