CVE-2024-44990

What it actually does

Null pointer dereference in bond_ipsec_offload_ok when an active slave is absent, leading to kernel crash (availability impact only).

Why it matters to the business

Local users on affected Linux systems using network bonding with IPsec offload can trigger denial of service; widespread kernel deployments increase exposure but low exploitability limits ransomware or remote risk.

How an attack unfolds

An attacker with local low-privileged access on a system using bonding triggers the IPsec offload path without an active slave present, causing the kernel to dereference a null pointer and panic.

How to fix it

Upgrade the Linux kernel to a version containing commit 81216b9352be43f8958092d379f6dec85443c309 or later stable releases that include the fix; disable IPsec offload on bonding interfaces as a temporary mitigation if patching is delayed.

How to confirm the fix worked

Verify the running kernel contains commit 81216b9352be43f8958092d379f6dec85443c309; inspect bonding driver source for the added active-slave check before pointer dereference; test IPsec offload paths under no-slave conditions.

Typical attack path

1. Obtain local shell or code execution on target Linux host
2. Configure or trigger bonding interface with IPsec offload enabled
3. Ensure no active slave exists at the moment of offload check
4. Invoke the vulnerable bond_ipsec_offload_ok path to dereference null pointer

How to detect it

Review kernel logs for null pointer dereference oops in bonding or ipsec_offload paths; correlate with bonding interface configuration changes or IPsec setup attempts by local processes.

What your security team should do

• Prioritize kernel updates on systems using bonding with IPsec offload
• Audit network configurations for bonding IPsec usage
• Monitor for local privilege or DoS attempts via kernel logs
• Apply the fix within standard patch cycles given low EPSS and absence from KEV