RE: [PATCH v4 net-next 07/14] net: enetc: add support for "Add" and "Delete" operations to IPFT

Wei Fang
2026-04-08T07:38:27Z

> > +int ntmp_ipft_add_entry(struct ntmp_user *user,
> > + struct ipft_entry_data *entry)
> > +{
> [ ... ]
> > + err = ntmp_alloc_data_mem(&data, (void **)&req);
> > + if (err)
> > + return err;
> > +
> > + ntmp_fill_crd(&req->crd, user->tbl.ipft_ver, NTMP_QA_ENTRY_ID,
> > + NTMP_GEN_UA_CFGEU | NTMP_GEN_UA_STSEU);
> > + req->ak.keye = entry->keye;
> > + req->cfge = entry->cfge;
>
> The request sets NTMP_GEN_UA_STSEU to indicate statistics data is present,
> but struct ipft_req_ua does not appear to contain a match_count or STSE data
> field before cfge.
>
> Since the hardware expects STSE data before CFGE data (as seen in
> struct ipft_resp_query), will this cause the hardware to misinterpret the
> first 8 bytes of cfge as the match_count, and then read the actual filter
> configuration from out-of-bounds or uninitialized memory?

Based on NETC manual, the STSE_DATA is present only for the commands
which perform a query. So for the 'add' command, we do not need to
provide the STSE_DATA buffer. And STSE_DATA is the statistics of the
entry, which is stored in the internal buffer of IPF table. Performing
NTMP_GEN_UA_STSEU is to reset the statistic counter when adding
an entry.

[...]

> > +struct ipft_pld_byte {
> > + u8 data;
> > + u8 mask;
> > +};
> > +
> > +struct ipft_keye_data {
> > + __le16 precedence;
> > + __le16 resv0[3];
> > + __le16 frm_attr_flags;
> > +#define IPFT_FAF_OVLAN BIT(2)
> > +#define IPFT_FAF_IVLAN BIT(3)
> > +#define IPFT_FAF_IP_HDR BIT(7)
> > +#define IPFT_FAF_IP_VER6 BIT(8)
> > +#define IPFT_FAF_L4_CODE GENMASK(11, 10)
> > +#define IPFT_FAF_TCP_HDR 1
> > +#define IPFT_FAF_UDP_HDR 2
> > +#define IPFT_FAF_SCTP_HDR 3
> > +#define IPFT_FAF_WOL_MAGIC BIT(12)
> > + __le16 frm_attr_flags_mask;
> > + __le16 dscp;
> > +#define IPFT_DSCP GENMASK(5, 0)
> > +#define IPFT_DSCP_MASK GENMASK(11, 0)
>
> Does IPFT_DSCP_MASK completely overlap with IPFT_DSCP?
>
> If it is defined as GENMASK(11, 0) instead of GENMASK(11, 6), using
> FIELD_PREP with this mask will not shift the value into the upper bits,
> which might overwrite the actual DSCP value in bits 0-5.

Thanks, this is a bug, I will fix it.