Re: [PATCH v3 01/13] preempt: Track NMI nesting to separate per-CPU counter

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Arithmetic overflow of `HARDIRQ_COUNT` carrying into `NMI_MASK` permanently corrupts `preempt_count` and causes a fatal kernel panic on nested NMI exit.
--

commit fea264f43839ad70d356b7c0bdb7708892c51c22
Author: Joel Fernandes <joelagnelf@nvidia.com>

preempt: Track NMI nesting to separate per-CPU counter

Move NMI nesting tracking from the preempt_count bits to a separate per-CPU
counter (nmi_nesting). This frees up the NMI bits in the preempt_count,
allowing those bits to be repurposed for other uses.

Link: https://patch.msgid.link/20260121223933.1568682-3-lyude@redhat.com

> diff --git a/include/linux/hardirq.h b/include/linux/hardirq.h
> --- a/include/linux/hardirq.h
> +++ b/include/linux/hardirq.h
> @@ -102,14 +104,17 @@ void irq_exit_rcu(void);
>   */
>  
>  /*
> - * nmi_enter() can nest up to 15 times; see NMI_BITS.
> + * nmi_enter() can nest - nesting is tracked in a per-CPU counter.
>   */
>  #define __nmi_enter()						\
>  	do {							\
>  		lockdep_off();					\
>  		arch_nmi_enter();				\
> -		BUG_ON(in_nmi() == NMI_MASK);			\
> -		__preempt_count_add(NMI_OFFSET + HARDIRQ_OFFSET);	\
> +		/* Maximum NMI nesting is 15. */		\
> +		BUG_ON(__this_cpu_read(nmi_nesting) >= 15);	\
> +		__this_cpu_inc(nmi_nesting);			\
> +		__preempt_count_add(HARDIRQ_OFFSET);		\
> +		preempt_count_set(preempt_count() | NMI_MASK);	\
>  	} while (0)

[ ... ]

>  #define nmi_enter()						\
> @@ -124,8 +129,12 @@ void irq_exit_rcu(void);
>  
>  #define __nmi_exit()						\
>  	do {							\
> +		unsigned int nesting;				\
>  		BUG_ON(!in_nmi());				\
> -		__preempt_count_sub(NMI_OFFSET + HARDIRQ_OFFSET);	\
> +		__preempt_count_sub(HARDIRQ_OFFSET);		\
> +		nesting = __this_cpu_dec_return(nmi_nesting);	\
> +		if (!nesting)					\
> +			preempt_count_set(preempt_count() & ~NMI_MASK);	\
>  		arch_nmi_exit();				\
>  		lockdep_on();					\
>  	} while (0)

[Severity: High]
Does this combination of __preempt_count_add() and bitwise OR in __nmi_enter()
break arithmetic symmetry when NMIs nest deeply?

Because HARDIRQ_BITS is 4, it can hold a maximum value of 15. The patch
explicitly allows NMI nesting up to 15 levels. If an NMI interrupts an active
hardirq (where the hardirq count is already 1) and then nests 15 times, the
total number of __preempt_count_add(HARDIRQ_OFFSET) operations reaches 16.

This overflows the 4-bit HARDIRQ field and carries a 1 into the NMI_MASK bit
(bit 20). The overflow mathematically clears bit 20 and sets bit 21. By then
forcing bit 20 back to 1 with a bitwise OR, the state is corrupted.

When the innermost NMI exits, __preempt_count_sub(HARDIRQ_OFFSET) subtracts
from this corrupted state, borrowing from bit 20 and clearing it. Because the
inner NMI does not explicitly restore NMI_MASK on exit (as nesting is 14),
it returns to the outer NMI with bit 20 cleared.

When the outer NMI eventually exits, won't it fail the BUG_ON(!in_nmi()) in
__nmi_exit() and trigger a kernel panic?

Also, doesn't this permanently leak a carry bit into the higher fields of
preempt_count (e.g., bit 21), which can accumulate and corrupt other states
like PREEMPT_NEED_RESCHED?

I note that a later patch in the series (commit "preempt: Introduce
HAS_SEPARATE_PREEMPT_RESCHED_BITS") fixes this for 64-bit architectures by
restoring the old algebraic logic, but 32-bit architectures without
CONFIG_HAS_SEPARATE_PREEMPT_RESCHED_BITS appear to continue using this flawed
bitwise-OR logic and remain vulnerable.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605054128.5925-1-boqun@kernel.org?part=1