CVE-2024-50136

What it actually does

Failure to unregister a notifier callback on eswitch init failure in mlx5 leaves it registered, causing duplicate registration warnings on subsequent mlx5_eswitch_enable calls.

Why it matters to the business

Kernel warnings during SR-IOV or eswitch reconfiguration on Mellanox adapters can complicate troubleshooting and delay network or virtualization operations in production environments.

How an attack unfolds

An operator or automated script triggers an eswitch initialization failure followed by a retry; the still-registered notifier produces a warning in notifier_chain_register, with no path to code execution or privilege escalation.

How to fix it

Upgrade the Linux kernel to the fixed commit ffc253263a1375a65fa6c9f62a893e9767fbebfa or later; rebuild and reboot with the patched mlx5_core module.

How to confirm the fix worked

Confirm the commit is present in the running kernel source; reproduce an eswitch init failure followed by a retry and verify the warning no longer appears.

Typical attack path

1. Cause mlx5_eswitch_enable_locked to fail during initial setup
2. Issue a subsequent sriov_numvfs_store or mlx5_core_sriov_configure call
3. Observe WARNING in atomic_notifier_chain_register from the duplicate eswitch_vport_event registration

How to detect it

Search kernel logs for the exact warning text notifier callback eswitch_vport_event already registered and the associated call trace through mlx5_eswitch_enable_locked.

• notifier callback eswitch_vport_event [mlx5_core] already registered
• WARNING: CPU:.*at kernel/notifier.c:.*notifier_chain_register
• mlx5_eswitch_enable_locked+0x1d4/0x3b0 [mlx5_core]

What your security team should do

• Prioritize kernel update on systems using mlx5 SR-IOV or eswitch features
• Add the duplicate-notifier warning string to monitoring rules
• Test eswitch reconfiguration workflows after patching