Commit Graph

12 Commits

Author SHA1 Message Date
CKI Backport Bot 8eb76c3a99 net: bridge: mst: fix suspicious rcu usage in br_mst_set_state
JIRA: https://issues.redhat.com/browse/RHEL-43727
CVE: CVE-2024-36979

commit 546ceb1dfdac866648ec959cbc71d9525bd73462
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Sun Jun 9 13:36:54 2024 +0300

    net: bridge: mst: fix suspicious rcu usage in br_mst_set_state

    I converted br_mst_set_state to RCU to avoid a vlan use-after-free
    but forgot to change the vlan group dereference helper. Switch to vlan
    group RCU deref helper to fix the suspicious rcu usage warning.

    Fixes: 3a7c1661ae13 ("net: bridge: mst: fix vlan use-after-free")
    Reported-by: syzbot+9bbe2de1bc9d470eb5fe@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=9bbe2de1bc9d470eb5fe
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Link: https://lore.kernel.org/r/20240609103654.914987-3-razor@blackwall.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com>
2024-08-06 13:05:41 +00:00
CKI Backport Bot 872266afb7 net: bridge: mst: pass vlan group directly to br_mst_vlan_set_state
JIRA: https://issues.redhat.com/browse/RHEL-43727
CVE: CVE-2024-36979

commit 36c92936e868601fa1f43da6758cf55805043509
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Sun Jun 9 13:36:53 2024 +0300

    net: bridge: mst: pass vlan group directly to br_mst_vlan_set_state

    Pass the already obtained vlan group pointer to br_mst_vlan_set_state()
    instead of dereferencing it again. Each caller has already correctly
    dereferenced it for their context. This change is required for the
    following suspicious RCU dereference fix. No functional changes
    intended.

    Fixes: 3a7c1661ae13 ("net: bridge: mst: fix vlan use-after-free")
    Reported-by: syzbot+9bbe2de1bc9d470eb5fe@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=9bbe2de1bc9d470eb5fe
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Link: https://lore.kernel.org/r/20240609103654.914987-2-razor@blackwall.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com>
2024-08-06 13:05:40 +00:00
CKI Backport Bot 26995111ab net: bridge: mst: fix vlan use-after-free
JIRA: https://issues.redhat.com/browse/RHEL-43727
CVE: CVE-2024-36979

commit 3a7c1661ae1383364cd6092d851f5e5da64d476b
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Mon May 13 14:06:27 2024 +0300

    net: bridge: mst: fix vlan use-after-free

    syzbot reported a suspicious rcu usage[1] in bridge's mst code. While
    fixing it I noticed that nothing prevents a vlan to be freed while
    walking the list from the same path (br forward delay timer). Fix the rcu
    usage and also make sure we are not accessing freed memory by making
    br_mst_vlan_set_state use rcu read lock.

    [1]
     WARNING: suspicious RCU usage
     6.9.0-rc6-syzkaller #0 Not tainted
     -----------------------------
     net/bridge/br_private.h:1599 suspicious rcu_dereference_protected() usage!
     ...
     stack backtrace:
     CPU: 1 PID: 8017 Comm: syz-executor.1 Not tainted 6.9.0-rc6-syzkaller #0
     Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
     Call Trace:
      <IRQ>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
      lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712
      nbp_vlan_group net/bridge/br_private.h:1599 [inline]
      br_mst_set_state+0x1ea/0x650 net/bridge/br_mst.c:105
      br_set_state+0x28a/0x7b0 net/bridge/br_stp.c:47
      br_forward_delay_timer_expired+0x176/0x440 net/bridge/br_stp_timer.c:88
      call_timer_fn+0x18e/0x650 kernel/time/timer.c:1793
      expire_timers kernel/time/timer.c:1844 [inline]
      __run_timers kernel/time/timer.c:2418 [inline]
      __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2429
      run_timer_base kernel/time/timer.c:2438 [inline]
      run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2448
      __do_softirq+0x2c6/0x980 kernel/softirq.c:554
      invoke_softirq kernel/softirq.c:428 [inline]
      __irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633
      irq_exit_rcu+0x9/0x30 kernel/softirq.c:645
      instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]
      sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043
      </IRQ>
      <TASK>
     asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
     RIP: 0010:lock_acquire+0x264/0x550 kernel/locking/lockdep.c:5758
     Code: 2b 00 74 08 4c 89 f7 e8 ba d1 84 00 f6 44 24 61 02 0f 85 85 01 00 00 41 f7 c7 00 02 00 00 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 25 00 00 00 00 00 43 c7 44 25 09 00 00 00 00 43 c7 44 25
     RSP: 0018:ffffc90013657100 EFLAGS: 00000206
     RAX: 0000000000000001 RBX: 1ffff920026cae2c RCX: 0000000000000001
     RDX: dffffc0000000000 RSI: ffffffff8bcaca00 RDI: ffffffff8c1eaa60
     RBP: ffffc90013657260 R08: ffffffff92efe507 R09: 1ffffffff25dfca0
     R10: dffffc0000000000 R11: fffffbfff25dfca1 R12: 1ffff920026cae28
     R13: dffffc0000000000 R14: ffffc90013657160 R15: 0000000000000246

    Fixes: ec7328b59176 ("net: bridge: mst: Multiple Spanning Tree (MST) mode")
    Reported-by: syzbot+fa04eb8a56fd923fc5d8@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=fa04eb8a56fd923fc5d8
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com>
2024-08-06 13:05:38 +00:00
Ivan Vecera ad56a16232 net: bridge: mst: Add helper to query a port's MST state
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2081601

commit f54fd0e163068ced4d0d27db64cd3cbda95b74e4
Author: Tobias Waldekranz <tobias@waldekranz.com>
Date:   Wed Mar 16 16:08:51 2022 +0100

    net: bridge: mst: Add helper to query a port's MST state

    This is useful for switchdev drivers who are offloading MST states
    into hardware. As an example, a driver may wish to flush the FDB for a
    port when it transitions from forwarding to blocking - which means
    that the previous state must be discoverable.

    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
2022-05-04 09:55:36 +02:00
Ivan Vecera bf2800f451 net: bridge: mst: Add helper to check if MST is enabled
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2081601

commit 48d57b2e5f439246c4e12ed7705a5e3241294b03
Author: Tobias Waldekranz <tobias@waldekranz.com>
Date:   Wed Mar 16 16:08:50 2022 +0100

    net: bridge: mst: Add helper to check if MST is enabled

    This is useful for switchdev drivers that might want to refuse to join
    a bridge where MST is enabled, if the hardware can't support it.

    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
2022-05-04 09:55:36 +02:00
Ivan Vecera d5b91247b7 net: bridge: mst: Add helper to map an MSTI to a VID set
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2081601

commit cceac97afa090284b3ceecd93ea6b7b527116767
Author: Tobias Waldekranz <tobias@waldekranz.com>
Date:   Wed Mar 16 16:08:49 2022 +0100

    net: bridge: mst: Add helper to map an MSTI to a VID set

    br_mst_get_info answers the question: "On this bridge, which VIDs are
    mapped to the given MSTI?"

    This is useful in switchdev drivers, which might have to fan-out
    operations, relating to an MSTI, per VLAN.

    An example: When a port's MST state changes from forwarding to
    blocking, a driver may choose to flush the dynamic FDB entries on that
    port to get faster reconvergence of the network, but this should only
    be done in the VLANs that are managed by the MSTI in question.

    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
2022-05-04 09:55:36 +02:00
Ivan Vecera 4b4d1425e2 net: bridge: mst: Notify switchdev drivers of MST state changes
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2081601

commit 7ae9147f4312903b97eae231c48571bbd95dc63f
Author: Tobias Waldekranz <tobias@waldekranz.com>
Date:   Wed Mar 16 16:08:48 2022 +0100

    net: bridge: mst: Notify switchdev drivers of MST state changes

    Generate a switchdev notification whenever an MST state changes. This
    notification is keyed by the VLANs MSTI rather than the VID, since
    multiple VLANs may share the same MST instance.

    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
2022-05-04 09:55:36 +02:00
Ivan Vecera 49e2fa557d net: bridge: mst: Notify switchdev drivers of VLAN MSTI migrations
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2081601

commit 6284c723d9b9995cc27ab3c6368a9d95d67111ff
Author: Tobias Waldekranz <tobias@waldekranz.com>
Date:   Wed Mar 16 16:08:47 2022 +0100

    net: bridge: mst: Notify switchdev drivers of VLAN MSTI migrations

    Whenever a VLAN moves to a new MSTI, send a switchdev notification so
    that switchdevs can track a bridge's VID to MSTI mappings.

    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
2022-05-04 09:55:36 +02:00
Ivan Vecera ec5ff364eb net: bridge: mst: Notify switchdev drivers of MST mode changes
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2081601

commit 87c167bb94ee3fd49569d4aa2038b9b8840d906f
Author: Tobias Waldekranz <tobias@waldekranz.com>
Date:   Wed Mar 16 16:08:46 2022 +0100

    net: bridge: mst: Notify switchdev drivers of MST mode changes

    Trigger a switchdev event whenever the bridge's MST mode is
    enabled/disabled. This allows constituent ports to either perform any
    required hardware config, or refuse the change if it not supported.

    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
2022-05-04 09:55:36 +02:00
Ivan Vecera c325872fd2 net: bridge: mst: Support setting and reporting MST port states
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2081601

commit 122c29486e1ff78033c45d0d31c710e7dc8945a5
Author: Tobias Waldekranz <tobias@waldekranz.com>
Date:   Wed Mar 16 16:08:45 2022 +0100

    net: bridge: mst: Support setting and reporting MST port states

    Make it possible to change the port state in a given MSTI by extending
    the bridge port netlink interface (RTM_SETLINK on PF_BRIDGE).The
    proposed iproute2 interface would be:

        bridge mst set dev <PORT> msti <MSTI> state <STATE>

    Current states in all applicable MSTIs can also be dumped via a
    corresponding RTM_GETLINK. The proposed iproute interface looks like
    this:

    $ bridge mst
    port              msti
    vb1               0
                        state forwarding
                      100
                        state disabled
    vb2               0
                        state forwarding
                      100
                        state forwarding

    The preexisting per-VLAN states are still valid in the MST
    mode (although they are read-only), and can be queried as usual if one
    is interested in knowing a particular VLAN's state without having to
    care about the VID to MSTI mapping (in this example VLAN 20 and 30 are
    bound to MSTI 100):

    $ bridge -d vlan
    port              vlan-id
    vb1               10
                        state forwarding mcast_router 1
                      20
                        state disabled mcast_router 1
                      30
                        state disabled mcast_router 1
                      40
                        state forwarding mcast_router 1
    vb2               10
                        state forwarding mcast_router 1
                      20
                        state forwarding mcast_router 1
                      30
                        state forwarding mcast_router 1
                      40
                        state forwarding mcast_router 1

    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
2022-05-04 09:55:35 +02:00
Ivan Vecera 5b97966f6c net: bridge: mst: Allow changing a VLAN's MSTI
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2081601

commit 8c678d60562f3e5f6d0a5f5465e27930ffedb8ca
Author: Tobias Waldekranz <tobias@waldekranz.com>
Date:   Wed Mar 16 16:08:44 2022 +0100

    net: bridge: mst: Allow changing a VLAN's MSTI

    Allow a VLAN to move out of the CST (MSTI 0), to an independent tree.

    The user manages the VID to MSTI mappings via a global VLAN
    setting. The proposed iproute2 interface would be:

        bridge vlan global set dev br0 vid <VID> msti <MSTI>

    Changing the state in non-zero MSTIs is still not supported, but will
    be addressed in upcoming changes.

    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
2022-05-04 09:55:35 +02:00
Ivan Vecera 14df6d5705 net: bridge: mst: Multiple Spanning Tree (MST) mode
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2081601

commit ec7328b59176227216c461601c6bd0e922232a9b
Author: Tobias Waldekranz <tobias@waldekranz.com>
Date:   Wed Mar 16 16:08:43 2022 +0100

    net: bridge: mst: Multiple Spanning Tree (MST) mode

    Allow the user to switch from the current per-VLAN STP mode to an MST
    mode.

    Up to this point, per-VLAN STP states where always isolated from each
    other. This is in contrast to the MSTP standard (802.1Q-2018, Clause
    13.5), where VLANs are grouped into MST instances (MSTIs), and the
    state is managed on a per-MSTI level, rather that at the per-VLAN
    level.

    Perhaps due to the prevalence of the standard, many switching ASICs
    are built after the same model. Therefore, add a corresponding MST
    mode to the bridge, which we can later add offloading support for in a
    straight-forward way.

    For now, all VLANs are fixed to MSTI 0, also called the Common
    Spanning Tree (CST). That is, all VLANs will follow the port-global
    state.

    Upcoming changes will make this actually useful by allowing VLANs to
    be mapped to arbitrary MSTIs and allow individual MSTI states to be
    changed.

    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
2022-05-04 09:55:35 +02:00