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))
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
linux-stable-mirror@lists.linaro.org
-
Arnd Bergmann -
Greg Kroah-Hartman -
Miaoqian Lin