CVE-2024-49999

What it actually does

Null pointer dereference in afs_wait_for_operation() when the fileserver iteration loop exits after discarding a server response, allowing op->server to remain NULL before the responded flag is written.

Why it matters to the business

May trigger kernel crashes or memory corruption on Linux systems using the AFS client, leading to service outages in environments that depend on stable AFS mounts; low overall exposure because specific AFS operation sequences are required.

How an attack unfolds

An attacker with network access to an AFS fileserver forces an operation loop to complete with an abort or partial data response that gets discarded, leaving op->server NULL so the subsequent flag write causes a crash or corruption.

How to fix it

Update the Linux kernel to commit 3d51ab44123f35dd1d646d99a15ebef10f55e263 or later; for Rocky Linux 8 update libsolv to 0.7.16-3.el8_4 or newer. Reboot after kernel package installation.

How to confirm the fix worked

Verify the running kernel contains commit 3d51ab44123f35dd1d646d99a15ebef10f55e263 and confirm absence of the original NULL dereference path via source inspection or kernel symbol checks.

Typical attack path

1. Establish AFS client connection to a controlled or compromised fileserver
2. Send responses that trigger loop exit with discarded server record
3. Trigger the missing NULL check path in afs_wait_for_operation()
4. Cause kernel panic or memory corruption

How to detect it

Review kernel logs for oops or panic messages referencing afs_wait_for_operation or server responded flag; no widespread in-the-wild exploitation artifacts are known.

What your security team should do

• Apply the listed kernel and libsolv updates within normal patch windows given low EPSS and no KEV listing
• Monitor for AFS-related kernel oops in system logs on any remaining unpatched systems
• Limit AFS client usage to trusted networks until updates are complete