CVE-2024-57996

5.5 MEDIUM

📋 TL;DR

A Linux kernel vulnerability in the Stochastic Fair Queueing (SFQ) network scheduler allows an array index out-of-bounds access when configured with a 1-packet limit. This can cause kernel crashes (denial of service) and potentially lead to memory corruption. Systems using Linux kernels with SFQ qdisc configured with limit=1 are affected.

💻 Affected Systems

Products:
  • Linux kernel
Versions: Versions before the fix commits (specific versions vary by distribution)
Operating Systems: Linux distributions using vulnerable kernel versions
Default Config Vulnerable: ✅ No
Notes: Only vulnerable when SFQ qdisc is configured with limit=1. Default configurations are not vulnerable.

📦 What is this software?

Linux Kernel by Linux

The Linux Kernel is the core component of the Linux operating system, serving as the critical interface between computer hardware and software processes. As the heart of millions of servers, cloud infrastructure, embedded systems, Android devices, and IoT deployments worldwide, the Linux Kernel mana...

Learn more about Linux Kernel →

Linux Kernel by Linux

The Linux Kernel is the core component of the Linux operating system, serving as the critical interface between computer hardware and software processes. As the heart of millions of servers, cloud infrastructure, embedded systems, Android devices, and IoT deployments worldwide, the Linux Kernel mana...

Learn more about Linux Kernel →

Linux Kernel by Linux

The Linux Kernel is the core component of the Linux operating system, serving as the critical interface between computer hardware and software processes. As the heart of millions of servers, cloud infrastructure, embedded systems, Android devices, and IoT deployments worldwide, the Linux Kernel mana...

Learn more about Linux Kernel →

Linux Kernel by Linux

The Linux Kernel is the core component of the Linux operating system, serving as the critical interface between computer hardware and software processes. As the heart of millions of servers, cloud infrastructure, embedded systems, Android devices, and IoT deployments worldwide, the Linux Kernel mana...

Learn more about Linux Kernel →

⚠️ Risk & Real-World Impact

🔴

Worst Case

Kernel panic leading to system crash and denial of service, with potential for memory corruption that could be leveraged for privilege escalation.

🟠

Likely Case

System crash/denial of service when specific network conditions trigger the bug, requiring system reboot.

🟢

If Mitigated

No impact if SFQ is not used or configured with limit>1.

🌐 Internet-Facing: MEDIUM - Requires specific network traffic patterns and SFQ configuration, but could be triggered remotely via network packets.
🏢 Internal Only: MEDIUM - Same technical risk but requires internal network access to trigger.

🎯 Exploit Status

Public PoC: ⚠️ Yes
Weaponized: LIKELY
Unauthenticated Exploit: ⚠️ Yes
Complexity: MEDIUM

Syzkaller has reproduced the crash. Exploit requires ability to configure network queues and send specific traffic patterns.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: Kernel versions with commits 10685681bafce6febb39770f3387621bf5d67d0b and related fixes

Vendor Advisory: https://git.kernel.org/stable/c/10685681bafce6febb39770f3387621bf5d67d0b

Restart Required: Yes

Instructions:

1. Update Linux kernel to patched version from your distribution. 2. Reboot system to load new kernel.

🔧 Temporary Workarounds

Avoid SFQ limit=1 configuration

linux

Prevent triggering the vulnerability by ensuring SFQ qdisc is not configured with limit=1

tc qdisc change dev <interface> parent <parent> sfq limit 2
tc qdisc del dev <interface> parent <parent> sfq

🧯 If You Can't Patch

  • Remove or reconfigure any SFQ qdisc with limit=1 to use limit>=2
  • Monitor for kernel panic/crash logs and implement high availability for critical systems

🔍 How to Verify

Check if Vulnerable:

Check if any SFQ qdisc is configured with limit=1: tc qdisc show | grep 'sfq.*limit 1'

Check Version:

uname -r

Verify Fix Applied:

Check kernel version is patched and verify no SFQ limit=1 configurations exist

📡 Detection & Monitoring

Log Indicators:

  • Kernel panic messages
  • UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c
  • System crash/reboot logs

Network Indicators:

  • Unusual network queue configurations with limit=1
  • Traffic patterns matching exploit scenario

SIEM Query:

source="kernel" AND ("UBSAN" OR "array-index-out-of-bounds" OR "sch_sfq")

🔗 References

📤 Share & Export