Received-SPF: pass (google.com: domain of linux-kernel+bounces-57990-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <tencent_6C6ACF8878B26D482FE56F649498E90EEF0A@qq.com>
From: Edward Adam Davis <eadavis@qq.com>
To: gregkh@linuxfoundation.org
Cc: eadavis@qq.com,
	linux-input@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org,
	rafael@kernel.org,
	syzbot+8e41bb0c055b209ebbf4@syzkaller.appspotmail.com,
	syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH riscv64] kobject: fix WARNING in input_register_device
Date: Thu,  8 Feb 2024 19:37:56 +0800
In-Reply-To: <2024020812-snowbound-version-6bfa@gregkh>
References: <2024020812-snowbound-version-6bfa@gregkh>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

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.