CVE-2021-47418 in Linux
Summary
by MITRE • 05/21/2024
In the Linux kernel, the following vulnerability has been resolved:
net_sched: fix NULL deref in fifo_set_limit()
syzbot reported another NULL deref in fifo_set_limit() [1]
I could repro the issue with :
unshare -n tc qd add dev lo root handle 1:0 tbf limit 200000 burst 70000 rate 100Mbit tc qd replace dev lo parent 1:0 pfifo_fast tc qd change dev lo root handle 1:0 tbf limit 300000 burst 70000 rate 100Mbit
pfifo_fast does not have a change() operation. Make fifo_set_limit() more robust about this.
[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 1cf99067 P4D 1cf99067 PUD 7ca49067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 14443 Comm: syz-executor959 Not tainted 5.15.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffffc9000e2f7310 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffffff8d6ecc00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff888024c27910 RDI: ffff888071e34000 RBP: ffff888071e34000 R08: 0000000000000001 R09: ffffffff8fcfb947 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888024c27910 R13: ffff888071e34018 R14: 0000000000000000 R15: ffff88801ef74800 FS: 00007f321d897700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 00000000722c3000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: fifo_set_limit net/sched/sch_fifo.c:242 [inline]
fifo_set_limit+0x198/0x210 net/sched/sch_fifo.c:227 tbf_change+0x6ec/0x16d0 net/sched/sch_tbf.c:418 qdisc_change net/sched/sch_api.c:1332 [inline]
tc_modify_qdisc+0xd9a/0x1a60 net/sched/sch_api.c:1634 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:704 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2025
The vulnerability CVE-2021-47418 represents a critical null pointer dereference in the Linux kernel's traffic control subsystem, specifically within the fifo_set_limit() function. This issue manifests when the kernel attempts to process network queue discipline changes through the traffic control interface, particularly when transitioning between different queue scheduling algorithms. The flaw occurs during the execution of tc commands that manipulate queue disciplines on loopback interfaces, where a sequence of operations involving TBF (Token Bucket Filter) and pfifo_fast scheduling algorithms creates a scenario where a null pointer is dereferenced, leading to a kernel oops and potential system instability.
The technical root cause stems from the absence of proper validation within the fifo_set_limit() function when handling queue discipline changes. When executing the specific sequence of tc commands provided in the reproduction case, the system attempts to replace a TBF queue discipline with a pfifo_fast queue discipline, which lacks a change() operation implementation. This mismatch causes the function to proceed with a null pointer dereference when trying to access queue discipline properties that do not exist for the pfifo_fast scheduler. The vulnerability is categorized under CWE-476 as a NULL pointer dereference, which represents a fundamental flaw in pointer validation and error handling within kernel space operations.
The operational impact of this vulnerability extends beyond simple system crashes, as it can be exploited to cause denial of service conditions in network-sensitive environments. Attackers could potentially leverage this weakness to disrupt network services by triggering the null pointer dereference through carefully crafted traffic control commands, particularly in systems where network management interfaces are exposed or accessible to unprivileged users. The vulnerability affects the kernel's networking subsystem and specifically targets the traffic control API implementation, making it particularly dangerous in containerized environments or systems where network resource management is critical. The issue was identified through automated fuzzing tools like syzbot, which demonstrated that the vulnerability could be reliably reproduced with a specific sequence of tc commands.
Mitigation strategies for this vulnerability primarily involve updating to kernel versions that include the patched implementation of fifo_set_limit() function, which properly validates queue discipline operations before attempting to access their properties. System administrators should prioritize kernel updates, particularly those containing the fix for the net_sched subsystem. Additionally, implementing proper access controls and network namespace restrictions can help limit exposure by preventing unprivileged users from executing potentially harmful tc commands. The fix implements robust error checking and null pointer validation within the queue discipline change handling code, ensuring that operations only proceed when valid queue discipline properties exist. Organizations should also consider monitoring for unusual network traffic control operations and implementing network segmentation to reduce the attack surface where such vulnerabilities might be exploited. This vulnerability aligns with ATT&CK technique T1068 by exploiting local system vulnerabilities to achieve privilege escalation or denial of service, and with T1562 by potentially disrupting system services through kernel-level instability.