Re: [PATCH v2] net/sched: act_skbedit: fix divide-by-zero in tcf_skbedit_hash()

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 12 Feb 2026 03:43:25 +0800 Ruitong Liu wrote:
> Commit 38a6f0865796 ("net: sched: support hash selecting tx queue")
> added SKBEDIT_F_TXQ_SKBHASH support. mapping_mod is computed as:
> 
>   mapping_mod = queue_mapping_max - queue_mapping + 1;
> 
> mapping_mod is stored as u16, so the calculation can overflow when the
> requested range covers 65536 queues (e.g. queue_mapping=0 and
> queue_mapping_max=0xffff). In that case mapping_mod wraps to 0 and
> tcf_skbedit_hash() triggers a divide-by-zero:
> 
>   queue_mapping += skb_get_hash(skb) % params->mapping_mod;
> 
> Reject such invalid configuration to prevent mapping_mod from becoming
> 0 and avoid the crash.

How did you find this bug? Do you have a repro to trigger the issue
you're describing?

> @@ -194,6 +194,10 @@ static int tcf_skbedit_init(struct net *net, struct nlattr *nla,
>  			}
>  
>  			mapping_mod = *queue_mapping_max - *queue_mapping + 1;
> +			if (!mapping_mod) {
> +				NL_SET_ERR_MSG_MOD(extack, "Invalid queue_mapping range: range too large");
> +				return -EINVAL;
> +			}
>  			flags |= SKBEDIT_F_TXQ_SKBHASH;
>  		}
>  		if (*pure_flags & SKBEDIT_F_INHERITDSFIELD)


There is this check right above the lines you're touching:

			if (*queue_mapping_max < *queue_mapping) {
				NL_SET_ERR_MSG_MOD(extack, "The range of queue_mapping is invalid, max < min.");
				return -EINVAL;
			}

I don't see how mapping_mod can be 0 here.
-- 
pw-bot: reject