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@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > Signed-off-by: Edward Adam Davis <eadavis@xxxxxx> > > > > --- > > > > 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.