netdev - Asymmetric br_mdb_notify calls when handling IGMPv3 joins/leaves

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

Date:   Mon, 14 Nov 2022 08:58:17 +0100
From:   Jacques de Laval <Jacques.De.Laval@...termo.com>
To:     <netdev@...r.kernel.org>
CC:     Nikolay Aleksandrov <razor@...ckwall.org>,
        Jacques de Laval <Jacques.De.Laval@...termo.com>
Subject: Asymmetric br_mdb_notify calls when handling IGMPv3 joins/leaves

Hi,

While testing the IGMP support in Linux I have observed that under certain
circumstances I can get an inconsistent state between the bridge mdb and
our Address Translation Unit (ATU). The root cause seems to be that the
bridge can issue more than one RTM_NEWMDB notification while handling a
single IGMP join (for a one port and group). When a later IGMP leave
is received for the same port and group it will not lead to more than one
RTM_DELMDB. The dsa layer however expects mdb notifications about added
and deleted entries to be symmetrical, ie. one DSA_NOTIFIER_MDB_DEL
received for a port should be preceded by no more than one
DSA_NOTIFIER_MDB_ADD for that port. If the notifications received are not
symmetrical, the reference counter for `struct dsa_mac_addr` might never
reach zero and the group will never be considered deleted in the
dsa layer.

The reason for the asymmetry in the bridge layer seems to be that
br_ip4_multicast_igmp3_report will potentially issue two RTM_NEWMDB
notifications when an IGMP join is received on an interface - one when
adding the group (via br_ip4_multicast_add_group) and then another one at
the end of the loop. An IGMP leave will only lead to one RTM_DELMDB (via
br_ip4_multicast_leave_group). I believe the same problem might exist
in br_ip6_multicast_mld2_report but I haven't tested that.

I don't feel that I grasp the logic in br_ip4_multicast_igmp3_report well
enough to be able to come up with a clean patch myself, does anyone else
have any idea? Am I right in my assumption that the bridge is at fault and
that the dsa layer should expect "symmetrical" adds and deletes?

Tested with a recent (e29edc4) net-next build.

Regards,
Jacques de Laval