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:

quoted

quoted

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.

quoted

quoted

Reported-and-tested-by: syzbot+8e41bb0c055b209ebbf4@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <redacted>
---
 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?

quoted

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