CVE-2021-47164

What it actually does

Null pointer dereference in the mlx5e driver when processing bonding enslave events before the upper device is initialized, leading to a kernel crash.

Why it matters to the business

Local denial of service that can crash systems using affected Mellanox network hardware with Linux bonding, disrupting network-dependent workloads until reboot.

How an attack unfolds

An attacker with local access triggers a bonding enslave operation that sends an event to mlx5e before the lag device pointer is valid, causing the driver to dereference null and panic the kernel.

How to fix it

Update the Linux kernel to a version containing the fix for the null dereference in net/mlx5e lag event handling; apply distribution security patches as they become available.

How to confirm the fix worked

Verify the running kernel contains the upstream commit that adds a null check for the lag device before processing events; test bonding enslave operations do not produce kernel oops.

Typical attack path

1. Obtain local shell or user context on a Linux system with mlx5e interfaces
2. Configure or modify a bonding master to enslave an mlx5e device
3. Trigger the first bonding event before upper device linkage completes
4. Cause kernel null dereference and system crash

How to detect it

Review kernel logs for oops or null pointer dereference messages involving mlx5e or lag device handling during bonding events; examine dmesg and syslog for crash signatures around network configuration changes.

What your security team should do

• Prioritize kernel updates on systems exposing mlx5e interfaces to untrusted local users
• Monitor for kernel panics on affected hardware during bonding changes
• Restrict local user access to network configuration commands until patched