Re: [PATCH v2] char: hpet: prevent hard-IRQ divide-by-zero in hpet_interrupt() via HPET_IRQFREQ

[krzk@kernel.org]

On Mon, 21 Sep 2026 02:20:19 +0000, Hui Peng wrote:
> In hpet_ioctl_common(), HPET_IRQFREQ computes the timer period as:
> 
>   devp->hd_ireqfreq = hpet_time_div(hpetp, arg);
> 
> where hpet_time_div() returns div64_ul(hpetp->hp_tick_freq + (arg >> 1),
> arg). Whenever arg > 2 * hpetp->hp_tick_freq, integer division truncates
> to 0 and stores devp->hd_ireqfreq = 0.
> 
> Although hpet_ioctl_ieon() (HPET_IE_ON) checks if (!devp->hd_ireqfreq)
> before enabling the timer interrupt, HPET_IRQFREQ neither rejects
> updates while HPET_IE is already active nor checks whether
> hpet_time_div(hpetp, arg) evaluates to 0. As a result, arming the timer
> with a valid frequency (for example, HPET_IRQFREQ with 1000 Hz followed
> by HPET_IE_ON) and then calling HPET_IRQFREQ with a large frequency (such
> as 0xffffffffUL) overwrites devp->hd_ireqfreq with 0 while the timer
> interrupt is active. When the next interrupt fires, hpet_interrupt()
> reads t = devp->hd_ireqfreq (0) and computes base = mc % t, crashing the
> kernel in hard-IRQ context:
> 
>   Oops: divide error: 0000 [#1] SMP KASAN PTI
>   CPU: 0 UID: 0 PID: 0 Comm: swapper/0
>   RIP: 0010:hpet_interrupt+0x20f/0x360
>   Call Trace:
>    <IRQ>
>    __handle_irq_event_percpu+0x102/0x400
>    handle_irq_event+0xa6/0x1c0
>    handle_level_irq+0x205/0x5e0
>    __common_interrupt+0x60/0x130
>    common_interrupt+0x7a/0x90
>    </IRQ>
>   Kernel panic - not syncing: Fatal exception in interrupt
> 
> Reject HPET_IRQFREQ with -EBUSY when HPET_IE is set in devp->hd_flags,
> and return -EINVAL when hpet_time_div(hpetp, arg) evaluates to 0.
> 
> Tested in QEMU (-global hpet.hpet-intcap=0x0c24 with noapic) by opening
> /dev/hpet and calling ioctl(fd, HPET_IRQFREQ, 1000), ioctl(fd,
> HPET_IE_ON, 0), and ioctl(fd, HPET_IRQFREQ, 0xffffffffUL): on the unfixed
> kernel this immediately triggers the divide error panic in
> hpet_interrupt(), whereas on the fixed kernel HPET_IRQFREQ returns -EBUSY
> while HPET_IE is enabled and -EINVAL when hpet_time_div(hpetp, arg) is 0.
> 
> Fixes: ba3f213f8a31 ("[PATCH] HPET: make frequency calculations 32 bit safe")
> Fixes: 273ef9509b79 ("drivers/char/hpet.c: fix periodic-emulation for delayed interrupts")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Hui Peng <benquike@gmail.com>
> ---
> Changes in v2:
> - Add Cc: stable@vger.kernel.org and include the QEMU test procedure and
>   oops trace in the commit description per Greg Kroah-Hartman.
> - Add Fixes: 273ef9509b79 ("drivers/char/hpet.c: fix periodic-emulation
>   for delayed interrupts") for the mc % t division in hpet_interrupt().
> 
>  drivers/char/hpet.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 


You sent multiple independent patches, to multiple independent
subsystems. The amount of these patches clearly suggest this was
AI generated and most likely not tested.

More importantly, you sent all this work without properly organizing
relevant patches into patchsets. This makes reviewing difficult
and might cause multiple reviewers to address the same issue.
Replying to the entire set is impossible and requires handling each
patch independently, instead of applying or discarding the set.
Maintainers also won't see the bigger picture of your work. Quite
worrying.

This is on the verge of hostile patch: bomb us with so many
contributions, we won't be able to handle them in efficient manner,
like responding ONCE to ask you to slow down.  Considering all this
is untested and LLM generated, I have even more doubts whether this
should be considered for review.

Please read kernel documentation BEFORE posting more work. It will
explain you how to identify subsystems, how to organize your work per
subsystem, how to document usage of LLM and how what you should not
do if this was posted in a good faith.

Best regards,
Krzysztof