Re: [PATCH net] dpaa2-switch: validate num_ifs to prevent out-of-bounds write

[Junrui Luo]

On Thu, Feb 19, 2026 at 02:14:07PM -0800, Jakub Kicinski wrote:
> > Reported-by: Yuhao Jiang <danisjiang@xxxxxxxxx>
> > Reported-by: Junrui Luo <moonafterrain@xxxxxxxxxxx>
> 
> Please remove the self-referential reported-by tags. FWIW:
> https://github.com/google/security-research/pull/334

Will drop in v2.

> 
> > Fixes: f054e3e217e4 ("dpaa2-switch: refactor the egress flooding domain setup")
> 
> This commit looks like refactoring.
> Please dig a bit deeper to find the real commit in which the bug was
> added.

I found the actual vulnerable pattern was introduced in:

539dda3c5d19 ("staging: dpaa2-switch: properly setup switching domains")

Will fix in v2.

> > +	if (ethsw->sw_attr.num_ifs >= DPSW_MAX_IF) {
> 
> Unclear to me from a quick look at the code and the commit message why
> we reject num_ifs == DPSW_MAX_IF. I see there are some references to a
> control interface in egress flooding, is that why?
> 
> Please explain clearly.

dpaa2_switch_fdb_get_flood_cfg() appends the control
interface entry after all matched ports:

      for (j = 0; j < ethsw->sw_attr.num_ifs; j++)
          if (port matches)
              cfg->if_id[i++] = ethsw->ports[j]->idx;

      cfg->if_id[i++] = ethsw->sw_attr.num_ifs;

When num_ifs == 64 and all ports match the flood filter, the loop
fills all 64 slots (indices 0-63), then the control interface write
goes to cfg->if_id[64].

Beyond the array overflow, num_ifs == 64 is also functionally broken:
build_if_id_bitmap() silently drops any ID >= 64:

      if (id[i] < DPSW_MAX_IF)
          bmap[id[i] / 64] |= ...

Will clarify this in the v2 commit message.

Thanks,
Junrui Luo