Message ID | tencent_AF9E941B3D4BEF1B2625D4BA18BBDA332108@qq.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-57883-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:50ea:b0:106:860b:bbdd with SMTP id r10csp78831dyd; Thu, 8 Feb 2024 02:47:36 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXrgJNNK2vO71n+dXYWx/ndOsBn9nokXKwTY5PXgkACMHi09kFZPvOWESOWyOVQv9D0l2ub2A8GNvVzIRb5FHVvWnd3vA== X-Google-Smtp-Source: AGHT+IGR/dLhBMs41ASjtdBf1HcKKUUnDRGTnSWzHUaZXsi8UYrihUTR/QFHDk7IQAELxZlld/ke X-Received: by 2002:a05:620a:6108:b0:785:a9b8:81c7 with SMTP id oq8-20020a05620a610800b00785a9b881c7mr603104qkn.53.1707389256740; Thu, 08 Feb 2024 02:47:36 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707389256; cv=pass; d=google.com; s=arc-20160816; b=YA8/ZmFtI5LO+rjk74SnNHClIt5NAHdIasu8/7SNW/RiyJddQHITa5grVT0gPPZlL2 4xs3c5BADJIh1u//rHngYHX/JtKsXs/qfGx4LiCcpzojIMs19IyyBqv6u0cUO2i0T5uu tvpHi3fWrOEeNbymftF7Kuh0EI1qoMhh5D6DTTs8jGTyfn13BlPAHPpwwdNg4jC0taof wLAXJXU7r3WfpwQzl+SGFRDtUnzAvYtY8s0Szgt06Je9R+a14J2tRVINTyW+14vkuucH hFbUSHMX2QvvxtLTjgqGatr5UbKLMJlgeM0rJ85NX+FDWCqhXvC1sV5EmhvTf+XechJ7 CUuw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:date :subject:cc:to:from:message-id:dkim-signature; bh=hcbbJhAls5Uesp7NyjBSOyZ/XNieAhW/QJoPzNlPnlQ=; fh=ulOlP8Qv5Oeioh8z09jnxNlKa4MqDp6T9uGdJoc+oa4=; b=q/YzuS1Pp3oTEpW/ktrWJ+Pd+2v0J7WN3Tj13KbCtQnJoOZNavbsLePMgxQl8p7F/7 NBuJxieuj2JJvl6NhMjSspiFfsAhEenRqzPlLYTGXIglUZpy4P4fxSV/n+BZSp45ZULi 7xLvs8juhsLTS+dwvxZC/zMmo9tziH/Ass6wz3pHkLukyTLOOTXYBk/dOVor2bXwKaKR dtazb94n0RBwD3G/VjHXoQGEtPLBj2yhLQxtJ/sFwPqgt0XKHv0Uiltd0CCC3ckzGMYP SZUMLtC24ZFk6BkjtOpnQ9TdYRgcnewx77UK+HUETylie+BFVUh8cLgqmiEmtZdIIlfF +hAA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@qq.com header.s=s201512 header.b="ac6vJ6/s"; arc=pass (i=1 spf=pass spfdomain=qq.com dkim=pass dkdomain=qq.com dmarc=pass fromdomain=qq.com); spf=pass (google.com: domain of linux-kernel+bounces-57883-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-57883-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=qq.com X-Forwarded-Encrypted: i=2; AJvYcCUfcbwDmm5hIkkCKTCgc9pdawd2DhuUDs2J36o2yCPS0AMBIgF3IdPE8ZjS+NR6+ByR9unsC6IpHsdxFoZ6F0qqEiniyQ== Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id v1-20020a05620a090100b007859f20c29fsi2528981qkv.616.2024.02.08.02.47.36 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Feb 2024 02:47:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-57883-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@qq.com header.s=s201512 header.b="ac6vJ6/s"; arc=pass (i=1 spf=pass spfdomain=qq.com dkim=pass dkdomain=qq.com dmarc=pass fromdomain=qq.com); spf=pass (google.com: domain of linux-kernel+bounces-57883-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-57883-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=qq.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 842311C229F1 for <ouuuleilei@gmail.com>; Thu, 8 Feb 2024 10:47:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A20916BB3E; Thu, 8 Feb 2024 10:47:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b="ac6vJ6/s" Received: from out203-205-221-173.mail.qq.com (out203-205-221-173.mail.qq.com [203.205.221.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 88A8C6D1CA; Thu, 8 Feb 2024 10:47:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=203.205.221.173 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707389233; cv=none; b=ZFgf7Xz9SGb9Gwlh29JNHpr/ccgG2Jm+EYVz9WSqcBnTifC2uPHyubjpWO9FfJh8Soay9wwBClBNOmJOz585IbXQRw4vd+GFGdik4ST8+B57Wa6luUF7pmdxFCOAcALwQDliGLP6heyxwMwDuIXD22CbZrhjCdCdcGfBjQT2kcc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707389233; c=relaxed/simple; bh=h7tpdDW4CcqCKn6XE4h5OZ+mpFGC6zQVQuoEeBaQ7bs=; h=Message-ID:From:To:Cc:Subject:Date:In-Reply-To:References: MIME-Version; b=iSWZ0fA8h8abFlN3CZ9zKBZzbVjxjwnPh+ubGAbnyVDzRXjqAJCn8Js2rjwyzrQfZeJ5BgL8ZvuZ+0MELtAeWn6IxkAzyfTxvTpC5V2OENaTzyXgVny58xZ+7TDKSXNKfJ/G4XOmIaPPRJjj55IqXgOaDKz4k9SLA1+ki96CY08= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com; spf=pass smtp.mailfrom=qq.com; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b=ac6vJ6/s; arc=none smtp.client-ip=203.205.221.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=qq.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1707389218; bh=hcbbJhAls5Uesp7NyjBSOyZ/XNieAhW/QJoPzNlPnlQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ac6vJ6/sCj8BTEThK4epPx9UY1M539mgYjxNZeZLBmCAJXTI2kxgox85oxT6Dk8Th wvOsO5koDxJl9IgHxzXdKZ3h2+1RcgO29os9V2lhvZr22/3Miqpef/K7ypv2xj15Gl 0JwDH8DJjhbQXI7PaWILj5gT13DixyDTIimvINik= Received: from pek-lxu-l1.wrs.com ([117.61.184.234]) by newxmesmtplogicsvrsza1-0.qq.com (NewEsmtp) with SMTP id BB7060B2; Thu, 08 Feb 2024 18:46:55 +0800 X-QQ-mid: xmsmtpt1707389215tzz8xjd5x Message-ID: <tencent_AF9E941B3D4BEF1B2625D4BA18BBDA332108@qq.com> X-QQ-XMAILINFO: OG0c0cMNDXpT/PABBA6BB72RIf0nVSzum1KsQAwIrzegiKAVPbaEAo0EP8zB5O j11mS800jDnC53o4K1MxB1EwZHZL+dKnHTHScDmIuOtCyH0fTAd5tOsvte1bGE7iA9B4AzmeiHBw 263vSIt3ZMrTfjhjo8i0grrzCPzhCfe/5pzWLgva+0fTIVNk3n7vY+919WjSxbU73yjX1mf/kx3x Tnp/lEN7NtFo79eQcJv+KYdFl+CypOiuuSMhkjXqXGLgK2E12GhZqJmAsH5yfBygYW57QCknmA+R G5JtVoXkJQ0jFNAd51SW7cZtebBV6zpeUBXFmS8sRd8ILo2I2UxJ/GMaMdrgks9SNRYkULS3/vL7 vipOxx6B8onz9GPZhfpAvkedCHj0YCSmbTNFzzqb11XUNrHOt2Tg6QmogUw/lkIelwkVhtxRQNQC 8rsJ0oE70dfDiBEsA76N1AiXwEtoiGkm54k+liMJzcoQDIKXN0sQ/xHEA2AY0MU007GpoYIEi3Nu iqQcXXmrmi8Jf+Rq+Q5pewdbbTCycy29SvqxsDvUqI1EzdLt1l1MrzqQ43WCCVWnI2cKogLwAs/7 N6T7zZZKaxtO4/iwkntrQCgMIzSrE6vXPL+6vblb4MqB7gNVrXoqjiU5l1CTlEb1Fq717LlI7vKn lckAJBO6nomDL+nyWaXFgbrK7BXWvbbZIPEDhD9WtSvcb2Tb5aC5Gmhc0aShJ0MAxl6LWXVPUfD6 lowP1P/TJdrjdL/0SHFvujr2eXeYqT/pcdBDr5tWTH82sSF+vho4J2lAB9i2I6FIB3Sp4fLndRY4 I9hxllZgp5iPOyZi1iLRf+1krkTOKLZJrF3+rhBBn5N5Pjhgq0fLDqSPsjmqTmtwG6+YNL5zBXtm GlL7YSG90usv4QEhWyyTtcI2gk7/A8cRoQYZtUqcYGQrSr/nI7n7XM877A4w4CiA== X-QQ-XMRINFO: NyFYKkN4Ny6FSmKK/uo/jdU= From: Edward Adam Davis <eadavis@qq.com> To: syzbot+8e41bb0c055b209ebbf4@syzkaller.appspotmail.com Cc: gregkh@linuxfoundation.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, rafael@kernel.org, syzkaller-bugs@googlegroups.com Subject: [PATCH riscv64] kobject: fix WARNING in input_register_device Date: Thu, 8 Feb 2024 18:46:55 +0800 X-OQ-MSGID: <20240208104654.3757719-2-eadavis@qq.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <00000000000047631d0610d010c1@google.com> References: <00000000000047631d0610d010c1@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790327397508201397 X-GMAIL-MSGID: 1790327397508201397 |
Series |
[riscv64] kobject: fix WARNING in input_register_device
|
|
Commit Message
Edward Adam Davis
Feb. 8, 2024, 10:46 a.m. UTC
The input_add_uevent_modalias_var()->input_print_modalias() will add 1684 bytes
of data to env, which will result in insufficient memory allocated to the buf
members of env.
Reported-and-tested-by: syzbot+8e41bb0c055b209ebbf4@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
include/linux/kobject.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Thu, Feb 08, 2024 at 06:46:55PM +0800, Edward Adam Davis wrote: > The input_add_uevent_modalias_var()->input_print_modalias() will add 1684 bytes > of data to env, which will result in insufficient memory allocated to the buf > members of env. What is "env"? And can you wrap your lines at 72 columns please? > Reported-and-tested-by: syzbot+8e41bb0c055b209ebbf4@syzkaller.appspotmail.com > Signed-off-by: Edward Adam Davis <eadavis@qq.com> > --- > include/linux/kobject.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/kobject.h b/include/linux/kobject.h > index c30affcc43b4..74b37b6459cd 100644 > --- a/include/linux/kobject.h > +++ b/include/linux/kobject.h > @@ -30,7 +30,7 @@ > > #define UEVENT_HELPER_PATH_LEN 256 > #define UEVENT_NUM_ENVP 64 /* number of env pointers */ > -#define UEVENT_BUFFER_SIZE 2048 /* buffer for the variables */ > +#define UEVENT_BUFFER_SIZE 2560 /* buffer for the variables */ That's an odd number, why that? Why not just a page? What happens if some other path wants more? And what's causing the input stack to have so many variables all of a sudden, what changed to cause this? Is this a bugfix for a specific commit that needs to be backported to older kernels? Why did this buffer size all of a sudden be too small? thanks, greg k-h
On Thu, 8 Feb 2024 10:56:00, Greg KH wrote: > > The input_add_uevent_modalias_var()->input_print_modalias() will add 1684 bytes > > of data to env, which will result in insufficient memory allocated to the buf > > members of env. > > What is "env"? And can you wrap your lines at 72 columns please? env is an instance of struct kobj_uevent_env. > > > Reported-and-tested-by: syzbot+8e41bb0c055b209ebbf4@syzkaller.appspotmail.com > > Signed-off-by: Edward Adam Davis <eadavis@qq.com> > > --- > > include/linux/kobject.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/include/linux/kobject.h b/include/linux/kobject.h > > index c30affcc43b4..74b37b6459cd 100644 > > --- a/include/linux/kobject.h > > +++ b/include/linux/kobject.h > > @@ -30,7 +30,7 @@ > > > > #define UEVENT_HELPER_PATH_LEN 256 > > #define UEVENT_NUM_ENVP 64 /* number of env pointers */ > > -#define UEVENT_BUFFER_SIZE 2048 /* buffer for the variables */ > > +#define UEVENT_BUFFER_SIZE 2560 /* buffer for the variables */ > > That's an odd number, why that? Why not just a page? What happens if > some other path wants more? An increase of 512 bytes is sufficient for the current issue. Do not consider the problem of hypothetical existence. > > And what's causing the input stack to have so many variables all of a > sudden, what changed to cause this? Is this a bugfix for a specific > commit that needs to be backported to older kernels? Why did this > buffer size all of a sudden be too small? The result of my analysis is that several members of struct input_dev are too large, such as its member keybit. thanks, edward.
On Thu, Feb 08, 2024 at 07:37:56PM +0800, Edward Adam Davis wrote: > On Thu, 8 Feb 2024 10:56:00, Greg KH wrote: > > > The input_add_uevent_modalias_var()->input_print_modalias() will add 1684 bytes > > > of data to env, which will result in insufficient memory allocated to the buf > > > members of env. > > > > What is "env"? And can you wrap your lines at 72 columns please? > env is an instance of struct kobj_uevent_env. Ok, be specific please in your changelog text, otherwise we can't really understand what is happening. > > > Reported-and-tested-by: syzbot+8e41bb0c055b209ebbf4@syzkaller.appspotmail.com > > > Signed-off-by: Edward Adam Davis <eadavis@qq.com> > > > --- > > > include/linux/kobject.h | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/include/linux/kobject.h b/include/linux/kobject.h > > > index c30affcc43b4..74b37b6459cd 100644 > > > --- a/include/linux/kobject.h > > > +++ b/include/linux/kobject.h > > > @@ -30,7 +30,7 @@ > > > > > > #define UEVENT_HELPER_PATH_LEN 256 > > > #define UEVENT_NUM_ENVP 64 /* number of env pointers */ > > > -#define UEVENT_BUFFER_SIZE 2048 /* buffer for the variables */ > > > +#define UEVENT_BUFFER_SIZE 2560 /* buffer for the variables */ > > > > That's an odd number, why that? Why not just a page? What happens if > > some other path wants more? > An increase of 512 bytes is sufficient for the current issue. Do not consider > the problem of hypothetical existence. Why is this 512 bytes sufficient now? What changed to cause this? And how can we detect this automatically in the future? Shouldn't we just be truncating the buffer instead of having an overflow? > > And what's causing the input stack to have so many variables all of a > > sudden, what changed to cause this? Is this a bugfix for a specific > > commit that needs to be backported to older kernels? Why did this > > buffer size all of a sudden be too small? > The result of my analysis is that several members of struct input_dev are too > large, such as its member keybit. And when did that change? What commit id? What prevents it from growing again and us needing to change this again? thanks, greg k-h
On Thu, Feb 08, 2024 at 07:37:56PM +0800, Edward Adam Davis wrote: > On Thu, 8 Feb 2024 10:56:00, Greg KH wrote: > > > The input_add_uevent_modalias_var()->input_print_modalias() will add 1684 bytes > > > of data to env, which will result in insufficient memory allocated to the buf > > > members of env. > > > > What is "env"? And can you wrap your lines at 72 columns please? > env is an instance of struct kobj_uevent_env. Also, why is "risc64" in the subject line? confused, greg k-h
On Thu, 8 Feb 2024 12:25:10 +0000, Greg KH wrote: > On Thu, Feb 08, 2024 at 07:37:56PM +0800, Edward Adam Davis wrote: > > On Thu, 8 Feb 2024 10:56:00, Greg KH wrote: > > > > The input_add_uevent_modalias_var()->input_print_modalias() will add 1684 bytes > > > > of data to env, which will result in insufficient memory allocated to the buf > > > > members of env. > > > > > > What is "env"? And can you wrap your lines at 72 columns please? > > env is an instance of struct kobj_uevent_env. > > Ok, be specific please in your changelog text, otherwise we can't really > understand what is happening. > > > > > Reported-and-tested-by: syzbot+8e41bb0c055b209ebbf4@syzkaller.appspotmail.com > > > > Signed-off-by: Edward Adam Davis <eadavis@qq.com> > > > > --- > > > > include/linux/kobject.h | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/include/linux/kobject.h b/include/linux/kobject.h > > > > index c30affcc43b4..74b37b6459cd 100644 > > > > --- a/include/linux/kobject.h > > > > +++ b/include/linux/kobject.h > > > > @@ -30,7 +30,7 @@ > > > > > > > > #define UEVENT_HELPER_PATH_LEN 256 > > > > #define UEVENT_NUM_ENVP 64 /* number of env pointers */ > > > > -#define UEVENT_BUFFER_SIZE 2048 /* buffer for the variables */ > > > > +#define UEVENT_BUFFER_SIZE 2560 /* buffer for the variables */ > > > > > > That's an odd number, why that? Why not just a page? What happens if > > > some other path wants more? > > An increase of 512 bytes is sufficient for the current issue. Do not consider > > the problem of hypothetical existence. > > Why is this 512 bytes sufficient now? What changed to cause this? There is the following code in input_print_modalias(): drivers/input/input.c 1 len += input_print_modalias_bits(buf + len, size - len, 1403 'k', id->keybit, KEY_MIN_INTERESTING, KEY_MAX); This code will add up to 2608 bytes of data to env at most. (KEY_MAX - KEY_MIN_INTERESTING) * 4 = (256 * 3 - 1 - 113 ) * 4 = (765 - 113) * 4 = 652 * 4 = 2608 bytes。 Note: In the expression, 4 represents 3 bytes of hexadecimal data and 1 byte of comma. include/uapi/linux/input-event-codes.h 188 #define KEY_MUTE 113 807 #define KEY_MIN_INTERESTING KEY_MUTE 808 #define KEY_MAX 0x2ff During my actual testing process, I found that a total of 1684 bytes were contributed in input_print_modalias(). > > And how can we detect this automatically in the future? Shouldn't we > just be truncating the buffer instead of having an overflow? > > > > And what's causing the input stack to have so many variables all of a > > > sudden, what changed to cause this? Is this a bugfix for a specific > > > commit that needs to be backported to older kernels? Why did this > > > buffer size all of a sudden be too small? > > The result of my analysis is that several members of struct input_dev are too > > large, such as its member keybit. > > And when did that change? What commit id? What prevents it from > growing again and us needing to change this again? The code that caused this issue has been introduced for a long time, and it is speculated that it was due to the fact that the warning in add_uevent_var() was returned directly to ENOMEM without being taken seriously. lib/kobject_uevent.c 2 if (len >= (sizeof(env->buf) - env->buflen)) { 1 WARN(1, KERN_ERR "add_uevent_var: buffer size too small\n"); 672 return -ENOMEM; 1 } I believe that this issue was introduced by: 7eff2e7a8b65 - Driver core: change add_ueventvar to use a struct. thanks, edward.
On Thu, 8 Feb 2024 12:25:35 +0000, Greg KH wrote: > On Thu, Feb 08, 2024 at 07:37:56PM +0800, Edward Adam Davis wrote: > > On Thu, 8 Feb 2024 10:56:00, Greg KH wrote: > > > > The input_add_uevent_modalias_var()->input_print_modalias() will add 1684 bytes > > > > of data to env, which will result in insufficient memory allocated to the buf > > > > members of env. > > > > > > What is "env"? And can you wrap your lines at 72 columns please? > > env is an instance of struct kobj_uevent_env. > > Also, why is "risc64" in the subject line? Because when syzbot reported this issue, it wrote "userspace arch: riscv64". However, I actually tested it on the master branch of upstream. thanks, edward.
On Tue, Feb 13, 2024 at 08:43:26AM +0800, Edward Adam Davis wrote: > On Thu, 8 Feb 2024 12:25:10 +0000, Greg KH wrote: > > On Thu, Feb 08, 2024 at 07:37:56PM +0800, Edward Adam Davis wrote: > > > On Thu, 8 Feb 2024 10:56:00, Greg KH wrote: > > > > > The input_add_uevent_modalias_var()->input_print_modalias() will add 1684 bytes > > > > > of data to env, which will result in insufficient memory allocated to the buf > > > > > members of env. > > > > > > > > What is "env"? And can you wrap your lines at 72 columns please? > > > env is an instance of struct kobj_uevent_env. > > > > Ok, be specific please in your changelog text, otherwise we can't really > > understand what is happening. > > > > > > > Reported-and-tested-by: syzbot+8e41bb0c055b209ebbf4@syzkaller.appspotmail.com > > > > > Signed-off-by: Edward Adam Davis <eadavis@qq.com> > > > > > --- > > > > > include/linux/kobject.h | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/include/linux/kobject.h b/include/linux/kobject.h > > > > > index c30affcc43b4..74b37b6459cd 100644 > > > > > --- a/include/linux/kobject.h > > > > > +++ b/include/linux/kobject.h > > > > > @@ -30,7 +30,7 @@ > > > > > > > > > > #define UEVENT_HELPER_PATH_LEN 256 > > > > > #define UEVENT_NUM_ENVP 64 /* number of env pointers */ > > > > > -#define UEVENT_BUFFER_SIZE 2048 /* buffer for the variables */ > > > > > +#define UEVENT_BUFFER_SIZE 2560 /* buffer for the variables */ > > > > > > > > That's an odd number, why that? Why not just a page? What happens if > > > > some other path wants more? > > > An increase of 512 bytes is sufficient for the current issue. Do not consider > > > the problem of hypothetical existence. > > > > Why is this 512 bytes sufficient now? What changed to cause this? > There is the following code in input_print_modalias(): > > drivers/input/input.c > 1 len += input_print_modalias_bits(buf + len, size - len, > 1403 'k', id->keybit, KEY_MIN_INTERESTING, KEY_MAX); > This code will add up to 2608 bytes of data to env at most. > (KEY_MAX - KEY_MIN_INTERESTING) * 4 = (256 * 3 - 1 - 113 ) * 4 = (765 - 113) * 4 = 652 * 4 = 2608 bytes。 > Note: In the expression, 4 represents 3 bytes of hexadecimal data and 1 byte of comma. So your change above is wrong and will not work for the max size? Why not restrict the modalias here to fit instead of overflowing? Odds are we should be checking this properly no matter what the value is changed to, right? > include/uapi/linux/input-event-codes.h > 188 #define KEY_MUTE 113 > 807 #define KEY_MIN_INTERESTING KEY_MUTE > 808 #define KEY_MAX 0x2ff > During my actual testing process, I found that a total of 1684 bytes were > contributed in input_print_modalias(). > > > > And how can we detect this automatically in the future? Shouldn't we > > just be truncating the buffer instead of having an overflow? > > > > > > And what's causing the input stack to have so many variables all of a > > > > sudden, what changed to cause this? Is this a bugfix for a specific > > > > commit that needs to be backported to older kernels? Why did this > > > > buffer size all of a sudden be too small? > > > The result of my analysis is that several members of struct input_dev are too > > > large, such as its member keybit. > > > > And when did that change? What commit id? What prevents it from > > growing again and us needing to change this again? > The code that caused this issue has been introduced for a long time, and it is > speculated that it was due to the fact that the warning in add_uevent_var() was > returned directly to ENOMEM without being taken seriously. > > lib/kobject_uevent.c > 2 if (len >= (sizeof(env->buf) - env->buflen)) { > 1 WARN(1, KERN_ERR "add_uevent_var: buffer size too small\n"); > 672 return -ENOMEM; Odd line numbers? Anyway, we should get rid of the WARN() as that will cause crashes, and just handle it properly there. > 1 } > > I believe that this issue was introduced by: > 7eff2e7a8b65 - Driver core: change add_ueventvar to use a struct. In 2007? And never been actually hit since then? So is this a real issue? :) thanks, greg k-h
On Tue, Feb 13, 2024 at 08:50:01AM +0800, Edward Adam Davis wrote: > On Thu, 8 Feb 2024 12:25:35 +0000, Greg KH wrote: > > On Thu, Feb 08, 2024 at 07:37:56PM +0800, Edward Adam Davis wrote: > > > On Thu, 8 Feb 2024 10:56:00, Greg KH wrote: > > > > > The input_add_uevent_modalias_var()->input_print_modalias() will add 1684 bytes > > > > > of data to env, which will result in insufficient memory allocated to the buf > > > > > members of env. > > > > > > > > What is "env"? And can you wrap your lines at 72 columns please? > > > env is an instance of struct kobj_uevent_env. > > > > Also, why is "risc64" in the subject line? > Because when syzbot reported this issue, it wrote "userspace arch: riscv64". > However, I actually tested it on the master branch of upstream. Then of course, this was not correct in the subject line. thanks, greg k-h
On Tue, 13 Feb 2024 08:20:52 +0100, Greg KH wrote: > On Thu, 8 Feb 2024 10:56:00, Greg KH wrote: > On Tue, Feb 13, 2024 at 08:43:26AM +0800, Edward Adam Davis wrote: > > On Thu, 8 Feb 2024 12:25:10 +0000, Greg KH wrote: > > > On Thu, Feb 08, 2024 at 07:37:56PM +0800, Edward Adam Davis wrote: > > > > On Thu, 8 Feb 2024 10:56:00, Greg KH wrote: > > > > > > The input_add_uevent_modalias_var()->input_print_modalias() will add 1684 bytes > > > > > > of data to env, which will result in insufficient memory allocated to the buf > > > > > > members of env. > > > > > > > > > > What is "env"? And can you wrap your lines at 72 columns please? > > > > env is an instance of struct kobj_uevent_env. > > > > > > Ok, be specific please in your changelog text, otherwise we can't really > > > understand what is happening. > > > > > > > > > Reported-and-tested-by: syzbot+8e41bb0c055b209ebbf4@syzkaller.appspotmail.com > > > > > > Signed-off-by: Edward Adam Davis <eadavis@qq.com> > > > > > > --- > > > > > > include/linux/kobject.h | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/include/linux/kobject.h b/include/linux/kobject.h > > > > > > index c30affcc43b4..74b37b6459cd 100644 > > > > > > --- a/include/linux/kobject.h > > > > > > +++ b/include/linux/kobject.h > > > > > > @@ -30,7 +30,7 @@ > > > > > > > > > > > > #define UEVENT_HELPER_PATH_LEN 256 > > > > > > #define UEVENT_NUM_ENVP 64 /* number of env pointers */ > > > > > > -#define UEVENT_BUFFER_SIZE 2048 /* buffer for the variables */ > > > > > > +#define UEVENT_BUFFER_SIZE 2560 /* buffer for the variables */ > > > > > > > > > > That's an odd number, why that? Why not just a page? What happens if > > > > > some other path wants more? > > > > An increase of 512 bytes is sufficient for the current issue. Do not consider > > > > the problem of hypothetical existence. > > > > > > Why is this 512 bytes sufficient now? What changed to cause this? > > There is the following code in input_print_modalias(): > > > > drivers/input/input.c > > 1 len += input_print_modalias_bits(buf + len, size - len, > > 1403 'k', id->keybit, KEY_MIN_INTERESTING, KEY_MAX); > > This code will add up to 2608 bytes of data to env at most. > > (KEY_MAX - KEY_MIN_INTERESTING) * 4 = (256 * 3 - 1 - 113 ) * 4 = (765 - 113) * 4 = 652 * 4 = 2608 bytes。 > > Note: In the expression, 4 represents 3 bytes of hexadecimal data and 1 byte of comma. > > So your change above is wrong and will not work for the max size? Yes. > > Why not restrict the modalias here to fit instead of overflowing? Odds > are we should be checking this properly no matter what the value is > changed to, right? Right. It may be necessary to deepen our understanding of this piece of code before fixing this issue internally. > > > include/uapi/linux/input-event-codes.h > > 188 #define KEY_MUTE 113 > > 807 #define KEY_MIN_INTERESTING KEY_MUTE > > 808 #define KEY_MAX 0x2ff > > During my actual testing process, I found that a total of 1684 bytes were > > contributed in input_print_modalias(). > > > > > > And how can we detect this automatically in the future? Shouldn't we > > > just be truncating the buffer instead of having an overflow? > > > > > > > > And what's causing the input stack to have so many variables all of a > > > > > sudden, what changed to cause this? Is this a bugfix for a specific > > > > > commit that needs to be backported to older kernels? Why did this > > > > > buffer size all of a sudden be too small? > > > > The result of my analysis is that several members of struct input_dev are too > > > > large, such as its member keybit. > > > > > > And when did that change? What commit id? What prevents it from > > > growing again and us needing to change this again? > > The code that caused this issue has been introduced for a long time, and it is > > speculated that it was due to the fact that the warning in add_uevent_var() was > > returned directly to ENOMEM without being taken seriously. > > > > lib/kobject_uevent.c > > 2 if (len >= (sizeof(env->buf) - env->buflen)) { > > 1 WARN(1, KERN_ERR "add_uevent_var: buffer size too small\n"); > > 672 return -ENOMEM; > > Odd line numbers? > > Anyway, we should get rid of the WARN() as that will cause crashes, and > just handle it properly there. > > > > 1 } > > > > I believe that this issue was introduced by: > > 7eff2e7a8b65 - Driver core: change add_ueventvar to use a struct. > > In 2007? And never been actually hit since then? So is this a real > issue? :) Yes. But as I mentioned earlier, in add_uevent_var(), it will exit directly after a warning, so this issue has not been given enough attention, perhaps it has happened many times. thanks, edward.
On Tue, 13 Feb 2024 08:21:18 +0100, Greg KH wrote: > On Tue, Feb 13, 2024 at 08:50:01AM +0800, Edward Adam Davis wrote: > > On Thu, 8 Feb 2024 12:25:35 +0000, Greg KH wrote: > > > On Thu, Feb 08, 2024 at 07:37:56PM +0800, Edward Adam Davis wrote: > > > > On Thu, 8 Feb 2024 10:56:00, Greg KH wrote: > > > > > > The input_add_uevent_modalias_var()->input_print_modalias() will add 1684 bytes > > > > > > of data to env, which will result in insufficient memory allocated to the buf > > > > > > members of env. > > > > > > > > > > What is "env"? And can you wrap your lines at 72 columns please? > > > > env is an instance of struct kobj_uevent_env. > > > > > > Also, why is "risc64" in the subject line? > > Because when syzbot reported this issue, it wrote "userspace arch: riscv64". > > However, I actually tested it on the master branch of upstream. > > Then of course, this was not correct in the subject line. Got it. thanks, edward.
diff --git a/include/linux/kobject.h b/include/linux/kobject.h index c30affcc43b4..74b37b6459cd 100644 --- a/include/linux/kobject.h +++ b/include/linux/kobject.h @@ -30,7 +30,7 @@ #define UEVENT_HELPER_PATH_LEN 256 #define UEVENT_NUM_ENVP 64 /* number of env pointers */ -#define UEVENT_BUFFER_SIZE 2048 /* buffer for the variables */ +#define UEVENT_BUFFER_SIZE 2560 /* buffer for the variables */ #ifdef CONFIG_UEVENT_HELPER /* path to the userspace helper executed on an event */