Re: [PATCH net] net: pktgen: reject out-of-range node indices

[Simon Horman <horms@kernel.org>]

On Thu, Sep 24, 2026 at 02:37:52PM +0900, Daehyeon Ko wrote:
> The pktgen node command parses up to ten decimal digits into unsigned
> long, then passes the value to node_possible(). That helper takes an int
> and tests the node bitmap without a bounds check. A value beyond the
> bitmap can read the next node-state mask and be accepted; larger values
> can narrow to a negative index. On 32-bit, parsing can also wrap.
> 
> On v7.2, an initial-namespace UID 65534 task with no effective
> capabilities reached pktgen_if_write() through user and network
> namespaces. KASAN reported an eight-byte wild read. The read can cause
> a crash; the proc result exposes a limited one-bit outcome. No broader
> memory disclosure or privilege escalation has been demonstrated.
> 
> Parse this command into u64 and reject node >= MAX_NUMNODES before
> converting to int. Preserve the existing OK/ERROR proc results. The
> fixed v7.2 KASAN VM passed nine input controls without a KASAN report;
> the W=1 pktgen object build was warning-free.
> 
> Introduced in v2.6.35, the unchecked call remains in v7.2.7 and
> v6.12.111 as checked on 2026-09-24. The read needs
> CONFIG_NET_PKTGEN and CONFIG_NUMA (MAX_NUMNODES > 1). The unprivileged
> path also needs usable CONFIG_USER_NS and CONFIG_NET_NS. Tested
> reproducer source is available privately to maintainers on request.
> 
> Fixes: e99b99b471c2 ("pktgen node allocation")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>

Thanks for your patch,

I have a few questions.

1.   Does this problem also exist for other callers of num_arg() ?

2.a. Could this be addressed by using kstrtoint() ?
     That seems like it would cover all values that currently work,
     and thus wouldn't change any working use-case.

2.b. Or, if not, some other standard helper?

2.c. Or, it not, could it be addressed by reducing the maximum digits?
     I am skeptical that 10^10 - 1 is a sensible value and thus
     reducing the range seems unlikely to break any legitimate use case.

...