Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp568403pxb; Fri, 8 Jan 2021 12:04:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJxuMi5sYF6IGZ7GVJkSwWEpjlCmM+unsL4dMSRgGr837+I1ZXeZE6OQ/8yGPMpQp9xC8KUk X-Received: by 2002:a17:906:8255:: with SMTP id f21mr3583113ejx.265.1610136254543; Fri, 08 Jan 2021 12:04:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610136254; cv=none; d=google.com; s=arc-20160816; b=zqYdYkDD2z/3sk3tU3sbalVKVvr8wvO3+AHCvLSD16grENVqMLpOCyMjsZ3Mw1GEos k4ULuxP+TZVFjfa+9dnbQfLv3yjRpa4zDxBtasZo53b3q0IX5WGeJbtmVGV88LYQERNu CV/+hOANHFRA9Ogfpa3JArkLsRlj3qrkrOkAXX2vgkdyp7Xf4QZ2dDlWiQxHRggNZHZt CSbyTK3idcSlsEajj8PN8XLH/YvsN+XajMqrFIyRcjhhnB3Fspmy6f7Hi3Z5ACk8wM6F Pah8GbNzkqobDvYYCpMRmA5M1XAStk5kt/rRnpNuh87KU/ZOeL+9V7/2OXEzeCsMTQ7A DIOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=oWemeIkyqGASs3SPb95T+f9gpYMwvjj7UK9XxPVbeps=; b=yChrmat98oz8KcaVdHNxN9gBn958z/JwsbY+Ac+ZtrR0nr3xL+Yt/aiJ9QLrDxRc26 1cycIRzgN5Bs4oJhrEWUwMNxJWmDQ6otyy+t4ucTrjyoAL2IplRcHCfi/pas98QL/vGT QQRw4h7wbz7IV/CYg7t/1PR6yggM2LogMkTqQEdd4OIc0TWfcT+pvsy9CkNAOvKBXZCB YLBFQxkup4EghJo+DxXo8eMDa/r8SG7aKFV1xc81G+x1QzACIxcL2mLLZalj7z7tA1jL VYjYV2sRaAzRiplJhNHa7juzDbTWoNrB6TTG+c1ZUnCYZFB/ms2JEKU7/fTjwcgQqTfw Fhuw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i3si3938622edj.120.2021.01.08.12.03.45; Fri, 08 Jan 2021 12:04:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728925AbhAHUDk (ORCPT + 99 others); Fri, 8 Jan 2021 15:03:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727161AbhAHUDk (ORCPT ); Fri, 8 Jan 2021 15:03:40 -0500 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21CB3C061381 for ; Fri, 8 Jan 2021 12:03:00 -0800 (PST) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94) (envelope-from ) id 1kxxxf-003h79-VK; Fri, 08 Jan 2021 21:02:54 +0100 Message-ID: <0efec65815ff9e26b3da69cb35d503a90086760c.camel@sipsolutions.net> Subject: Re: [PATCH] mac80211: fix incorrect strlen of .write in debugfs From: Johannes Berg To: Shayne Chen , linux-wireless Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Felix Fietkau , Lorenzo Bianconi , Ryder Lee , linux-mediatek , Sujuan Chen Date: Fri, 08 Jan 2021 21:02:53 +0100 In-Reply-To: <20210108105643.10834-1-shayne.chen@mediatek.com> References: <20210108105643.10834-1-shayne.chen@mediatek.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org This looks wrong to me, am I missing something? > diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c > index 9135b6f..9991a6a 100644 > --- a/net/mac80211/debugfs.c > +++ b/net/mac80211/debugfs.c > @@ -120,7 +120,6 @@ static ssize_t aqm_write(struct file *file, > { > struct ieee80211_local *local = file->private_data; > char buf[100]; > - size_t len; > > if (count > sizeof(buf)) > return -EINVAL; This ensures that count <= sizeof(buf) > @@ -128,10 +127,10 @@ static ssize_t aqm_write(struct file *file, > if (copy_from_user(buf, user_buf, count)) > return -EFAULT; We copy, that's fine. > - buf[sizeof(buf) - 1] = '\0'; > - len = strlen(buf); > - if (len > 0 && buf[len-1] == '\n') > - buf[len-1] = 0; > + if (count && buf[count - 1] == '\n') > + buf[count - 1] = '\0'; This I think really was meant as strlen, because if you write something like 10\n\0\0\0\0 before it would have parsed it as 10 still, now it gets confused? I guess I'm not worried about that though. > + buf[count] = '\0'; But if count == sizeof(buf) then this is an out-of-bounds write. Same for all the other copied instances. johannes