netdev - [PATCH] net : fix adding same ip rule multiple times

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 1 Mar 2023 14:50:15 +0100
From:   ismail bouzaiene <ismailbouzaiene@...il.com>
To:     netdev@...r.kernel.org, davem@...emloft.net,
        "edumazet@...gle.com" <edumazet@...gle.com>, kuba@...nel.org,
        pabeni@...hat.com
Subject: [PATCH] net : fix adding same ip rule multiple times

Hello,

In case we try to add the same ip rule multiple times, the kernel will
reject the addition using the call rule_exits().

However there are two use cases where it is still possible to add the
same ip rule multiple times despite the check rule_exists().

First use case :

add two ip rules with the same informations and only the prio / pref
attribute is different

Second use case :

add two ip rules with the same informations without setting the
attribute prio / pref
In this case, the kernel will attribute a pref to this ip rule using
the following mechanism :

Kernel will loop over all already applied ip rules, get the index of
the first ip rule with pref not null
add +1 and use this value to set the pref field in the ip rule to be applied.

The two use cases are possible because the call rule_exists() checks
the prio / pref among others parameters, and in both cases the prio /
pref attribute will be different from any of the already applied ip
rules.

I suggest fixing the mentioned two cases by removing the test on the
pref / prio attribute in the function rule_exits().

This patch implement the suggested solution : patch_solAllcases.patch

In case you think that the First use case is a valid use case and we
need only to handle the Second use case, I provide here also a second
patch that handle only the First use case :

patch_solOnlySecondCase.patch

View attachment "patch_solAllcases.patch" of type "text/x-patch" (488 bytes)

View attachment "patch_solOnlySecondCase.patch" of type "text/x-patch" (1039 bytes)