netdev - Re: [PATCH wpan/next v3 6/9] net: mac802154: Add promiscuous software filtering

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK-6q+h_Qwx7heyoEm+BW85bhWLRb+BotN9qzpuRycp+gJNuVw@mail.gmail.com>
Date:   Thu, 8 Sep 2022 20:44:11 -0400
From:   Alexander Aring <aahringo@...hat.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Alexander Aring <alex.aring@...il.com>,
        Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org,
        David Girault <david.girault@...vo.com>,
        Romuald Despres <romuald.despres@...vo.com>,
        Frederic Blain <frederic.blain@...vo.com>,
        Nicolas Schodet <nico@...fr.eu.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH wpan/next v3 6/9] net: mac802154: Add promiscuous software filtering

Hi,

On Mon, Sep 5, 2022 at 4:34 PM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> Currently, the promiscuous mode was not as open as it should. It was not
> a big deal because until now promiscuous modes were only used on monitor
> interfaces, which would never go this far in the filtering. But as we
> might now use this promiscuous mode with NODEs or COORDs, it becomes
> necessary to really forward the packets to the upper layers without

no, they should never deliver to upper layers in filtering modes where
address filtering is disabled.

> additional filtering when relevant. Let's add the necessary logic to
> handle this situation.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
> ---
>  net/mac802154/rx.c | 25 +++++++++++++++++++++++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/net/mac802154/rx.c b/net/mac802154/rx.c
> index bd1a92fceef7..8a8c5a4a2f28 100644
> --- a/net/mac802154/rx.c
> +++ b/net/mac802154/rx.c
> @@ -196,10 +196,31 @@ __ieee802154_rx_handle_packet(struct ieee802154_local *local,
>         int ret;
>         struct ieee802154_sub_if_data *sdata;
>         struct ieee802154_hdr hdr;
> +       struct sk_buff *skb2;
>
> +       /* Level 2 filtering: Avoid further processing in IEEE 802.15.4 promiscuous modes */
> +       list_for_each_entry_rcu(sdata, &local->interfaces, list) {
> +               if (!ieee802154_sdata_running(sdata))
> +                       continue;
> +
> +               if (sdata->required_filtering < IEEE802154_FILTERING_1_FCS ||
> +                   sdata->required_filtering > IEEE802154_FILTERING_2_PROMISCUOUS)
> +                       continue;
> +

I am confused about using "sdata->required_filtering" here.

> +               skb2 = skb_clone(skb, GFP_ATOMIC);
> +               if (skb2) {
> +                       skb2->dev = sdata->dev;
> +                       ieee802154_deliver_skb(skb2);
> +
> +                       sdata->dev->stats.rx_packets++;
> +                       sdata->dev->stats.rx_bytes += skb->len;
> +               }
> +       }
> +

I am confused about this change here.

- Alex