CVE-2025-21986

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: switchdev: Convert blocking notification chain to a raw one<br /> <br /> A blocking notification chain uses a read-write semaphore to protect the<br /> integrity of the chain. The semaphore is acquired for writing when<br /> adding / removing notifiers to / from the chain and acquired for reading<br /> when traversing the chain and informing notifiers about an event.<br /> <br /> In case of the blocking switchdev notification chain, recursive<br /> notifications are possible which leads to the semaphore being acquired<br /> twice for reading and to lockdep warnings being generated [1].<br /> <br /> Specifically, this can happen when the bridge driver processes a<br /> SWITCHDEV_BRPORT_UNOFFLOADED event which causes it to emit notifications<br /> about deferred events when calling switchdev_deferred_process().<br /> <br /> Fix this by converting the notification chain to a raw notification<br /> chain in a similar fashion to the netdev notification chain. Protect<br /> the chain using the RTNL mutex by acquiring it when modifying the chain.<br /> Events are always informed under the RTNL mutex, but add an assertion in<br /> call_switchdev_blocking_notifiers() to make sure this is not violated in<br /> the future.<br /> <br /> Maintain the "blocking" prefix as events are always emitted from process<br /> context and listeners are allowed to block.<br /> <br /> [1]:<br /> WARNING: possible recursive locking detected<br /> 6.14.0-rc4-custom-g079270089484 #1 Not tainted<br /> --------------------------------------------<br /> ip/52731 is trying to acquire lock:<br /> ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0<br /> <br /> but task is already holding lock:<br /> ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> CPU0<br /> ----<br /> lock((switchdev_blocking_notif_chain).rwsem);<br /> lock((switchdev_blocking_notif_chain).rwsem);<br /> <br /> *** DEADLOCK ***<br /> May be due to missing lock nesting notation<br /> 3 locks held by ip/52731:<br /> #0: ffffffff84f795b0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x727/0x1dc0<br /> #1: ffffffff8731f628 (&amp;net-&gt;rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x790/0x1dc0<br /> #2: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0<br /> <br /> stack backtrace:<br /> ...<br /> ? __pfx_down_read+0x10/0x10<br /> ? __pfx_mark_lock+0x10/0x10<br /> ? __pfx_switchdev_port_attr_set_deferred+0x10/0x10<br /> blocking_notifier_call_chain+0x58/0xa0<br /> switchdev_port_attr_notify.constprop.0+0xb3/0x1b0<br /> ? __pfx_switchdev_port_attr_notify.constprop.0+0x10/0x10<br /> ? mark_held_locks+0x94/0xe0<br /> ? switchdev_deferred_process+0x11a/0x340<br /> switchdev_port_attr_set_deferred+0x27/0xd0<br /> switchdev_deferred_process+0x164/0x340<br /> br_switchdev_port_unoffload+0xc8/0x100 [bridge]<br /> br_switchdev_blocking_event+0x29f/0x580 [bridge]<br /> notifier_call_chain+0xa2/0x440<br /> blocking_notifier_call_chain+0x6e/0xa0<br /> switchdev_bridge_port_unoffload+0xde/0x1a0<br /> ...