A malicious user could pass an arbitrarily bad value
to memdup_user_nul(), potentially causing kernel crash.

This follows the same pattern as commit ee76746387f6
("netdevsim: prevent bad user input in nsim_dev_health_break_write()")
and commit 7ef4c19d245f
("smackfs: restrict bytes count in smackfs write functions")

Found via static analysis and code review.

Fixes: 183238ffb886 ("misc: eeprom/idt_89hpesx: Switch to memdup_user_nul() helper")
Cc: stable@vger.kernel.org
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
---
 drivers/misc/eeprom/idt_89hpesx.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/misc/eeprom/idt_89hpesx.c b/drivers/misc/eeprom/idt_89hpesx.c
index 60c42170d147..b2e771bfc6da 100644
--- a/drivers/misc/eeprom/idt_89hpesx.c
+++ b/drivers/misc/eeprom/idt_89hpesx.c
@@ -907,6 +907,9 @@ static ssize_t idt_dbgfs_csr_write(struct file *filep, const char __user *ubuf,
 	if (*offp)
 		return 0;
 
+	if (count == 0 || count > PAGE_SIZE)
+		return -EINVAL;
+
 	/* Copy data from User-space */
 	buf = memdup_user_nul(ubuf, count);
 	if (IS_ERR(buf))
-- 
2.39.5 (Apple Git-154)

On Thu, Oct 30, 2025, at 06:28, Miaoqian Lin wrote:
> A malicious user could pass an arbitrarily bad value
> to memdup_user_nul(), potentially causing kernel crash.

I think you should be more specific than 'kernel crash' here.
As far as I can tell, the worst case would be temporarily
consuming a MAX_ORDER_NR_PAGES allocation, leading to out-of-memory.

> Fixes: 183238ffb886 ("misc: eeprom/idt_89hpesx: Switch to 
> memdup_user_nul() helper")

I don't think that patch changed anything, the same thing
would have happened with kmalloc()+copy_from_user().
Am I missing something?

> +	if (count == 0 || count > PAGE_SIZE)
> +		return -EINVAL;
> +

How did you pick PAGE_SIZE as the maximum here?

       Arnd

On Thu, Oct 30, 2025 at 09:47:22AM +0100, Arnd Bergmann wrote:
> On Thu, Oct 30, 2025, at 06:28, Miaoqian Lin wrote:
> > A malicious user could pass an arbitrarily bad value
> > to memdup_user_nul(), potentially causing kernel crash.
> 
> I think you should be more specific than 'kernel crash' here.
> As far as I can tell, the worst case would be temporarily
> consuming a MAX_ORDER_NR_PAGES allocation, leading to out-of-memory.

I think we already limit the size of writes so this shouldn't happen,
but a real trace would be good to see.

> > Fixes: 183238ffb886 ("misc: eeprom/idt_89hpesx: Switch to 
> > memdup_user_nul() helper")
> 
> I don't think that patch changed anything, the same thing
> would have happened with kmalloc()+copy_from_user().
> Am I missing something?
> 
> > +	if (count == 0 || count > PAGE_SIZE)
> > +		return -EINVAL;
> > +
> 
> How did you pick PAGE_SIZE as the maximum here?

I agree, that seems very very small.

thanks,

greg k-h