On Mon, Jul 17, 2023 at 01:07:35PM +0200, Pablo Neira Ayuso wrote:
> Hi Phil,
>
> On Sat, Jul 15, 2023 at 02:59:26PM +0200, Phil Sutter wrote:
> > When comparing matches for equality, trailing data in among match is not
> > considered. Therefore two matches with identical pairs count may be
> > treated as identical when the pairs actually differ.
>
> By "trailing data", you mean the right-hand side of this?
>
> fe:ed:ba:be:00:01=10.0.0.1
I mean field "pairs" in struct nft_among_data:
| struct nft_among_data {
| struct {
| size_t cnt;
| bool inv;
| bool ip;
| } src, dst;
| uint32_t pairs_hash;
| /* first source, then dest pairs */
| struct nft_among_pair pairs[0];
| };
So basically all pairs are being ignored. As long as the number and type (with
IP or not) of pairs and the invert flag matches, match data was considered
identical.
> > Matches' parsing callbacks have no access to the xtables_match itself,
> > so can't update userspacesize field as needed.
> >
> > To fix this, extend struct nft_among_data by a hash field to contain a
> > DJB hash of the trailing data.
>
> Is this DJB hash use subject to collisions?
Could be. I considered it "good enough", but didn't try how easy it is
to cause a collision. Are you suggesting to use a more secure algorithm?
Thanks, Phil
