Coder Legion - Recent posts tagged kernel

Patch These Four Linux Kernel Local Root Vulns Now: DirtyAH6, PPPoEject, TUNderflow, and DiagSpill

Sun, 25 Oct 2026 23:46:09 +0000

Originally published at codewithromi.com.
Four Linux kernel vulnerabilities went public on 18 September 2026, and they are the kind you should not sit on. DirtyAH6 (CVE-2026-80844), PPPoEject (CVE-2026-68121), TUNderflow (CVE-2026-81000) and DiagSpill (CVE-2026-74469) are all local privilege escalation bugs, meaning an attacker or malicious process with a foothold on your machine can escalate to root. Working proof of concept exploits for all four are public. If you are running Proxmox, a Raspberry Pi, or any self-hosted Linux node, this is a patching weekend.

Security researcher Asim Manizada reported the four bugs in mid July 2026 and published a technical write-up plus working exploits on 18 September 2026, after a coordinated hold so distributions could ship fixes first. The oss-security post and the accompanying write-up carry the per-CVE detail. Upstream, the earliest stable releases that contain all four fixes are 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4. Note that the 7.0 series reached end of life on 27 June 2026, so a 7.0 kernel only carries these fixes if your vendor backported them.

💡 Why This Matters for Homelabbers

Local root exploits are often dismissed as "low risk" because they require existing access. That framing misses the threat model for homelabs and self-hosted infrastructure. If any service you run gets compromised, a web app, an LXC container with a shared kernel, or even a rogue package, a local root bug turns that into full node ownership.

Proxmox LXC containers share the host kernel. A container breakout combined with a local priv-esc is a realistic attack chain. Raspberry Pi nodes running exposed services are in the same boat. Patch the kernel, then verify.

🧰 Prerequisites

SSH or console access to each node
sudo or root privileges
A maintenance window, since patching requires a reboot
Proxmox nodes: access to the Proxmox web UI or CLI for VM/container shutdown sequencing

🔧 Step-by-Step: Patching Your Nodes

Step 1: Check your current kernel version on every node so you know what you are starting from.

uname -r

Note this output. You will compare it after the update to confirm the new kernel is running.

Step 2: Update your package index and apply all available security updates. On Debian and Ubuntu based systems, including Proxmox and Raspberry Pi OS:

sudo apt update && sudo apt full-upgrade -y

On Proxmox specifically, you also want to pull from the Proxmox repositories. If you are on the no-subscription repo, this is already covered by the command above. Run pveversion -v afterward to confirm the Proxmox packages are current too.

Step 3: If you are running Raspberry Pi OS, check the kernel package by its current name. On Bullseye and earlier the kernel shipped in the raspberrypi-kernel package, but Raspberry Pi OS moved to Debian style linux-image-rpi-* packages with Bookworm, so on a current install you want linux-image-rpi-v8 or linux-image-rpi-2712 depending on the board. The apt full-upgrade command above will still catch it, but confirm with:

On Bookworm and newer:

apt-cache policy linux-image-rpi-v8

On Bullseye and older:

apt-cache policy raspberrypi-kernel

The "Installed" and "Candidate" versions should match after your upgrade. If they do not, run the upgrade again.

Step 4: Reboot to load the new kernel. This is not optional. The running kernel in memory is still the old one until you reboot.

sudo reboot

For Proxmox hosts, shut down or migrate your VMs and containers before rebooting the host. Use the Proxmox web UI, or list what is running:

qm list
pct list

Then shut down each VM or container by its ID:

qm shutdown [vmid]
pct shutdown [ctid]

Step 5: After the reboot, confirm the new kernel is loaded:

uname -r

The version string should be newer than what you recorded in Step 1. Cross-reference it against your distro's security advisory to confirm the patched version is in place. For Debian, check security-tracker.debian.org. For Ubuntu, check ubuntu.com/security/notices. For Raspberry Pi OS, check the Raspberry Pi blog and release notes.

🛡️ Patch Status, Checked 29 September 2026

This is the part of the post that goes stale fastest, so here is a dated snapshot. Everything below was checked against the Debian security tracker, the Ubuntu CVE tracker and the Proxmox kernel changelog on 29 September 2026. Re-check before you decide you are covered.

Debian 13 trixie: all four first fixed in linux 6.12.111-1, shipped as DSA-6528-1.
Debian 12 bookworm: DirtyAH6, PPPoEject and DiagSpill first fixed in linux 6.1.187-1 from bookworm-security. TUNderflow is the exception. The Debian tracker still lists bookworm as vulnerable, 6.1.187-1 included, so there is no fix for CVE-2026-81000 on bookworm yet.
Ubuntu 22.04, 24.04 and 26.04: at the time of this check the Ubuntu CVE tracker showed no released kernel for any of the four on the main linux packages. They sit at needed or pending. Watch ubuntu.com/security/notices instead of assuming an upgrade fixed it.
Proxmox VE: the Proxmox kernel changelog names only TUNderflow, first fixed in proxmox-kernel-7.0 version 7.0.14-19, released 18 September 2026. The newest build at the time of checking was 7.0.14-20 from 24 September 2026. The other three CVEs are not named anywhere in that changelog, and the Proxmox 7.0 kernel follows the Ubuntu kernel, which has not released them, so do not assume DirtyAH6, PPPoEject and DiagSpill are closed on a Proxmox host. Run pveversion -v and compare against the changelog.
Raspberry Pi OS: no Raspberry Pi OS kernel build carrying all four fixes could be confirmed at the time of this check. On the 6.12 branch you need 6.12.109 or newer for the full set, so check the installed package version rather than assuming.

🛡️ What Each Vulnerability Affects

Here is what each bug actually is, taken from the disclosure and the researcher's write-up. Three of the four need CAP_NET_ADMIN in a network namespace the attacker controls, which an ordinary local user obtains by creating an unprivileged user namespace first. DiagSpill is the exception and needs no special privileges at all.

DirtyAH6 (CVE-2026-80844): The IPv6 Authentication Header code in the IPsec and XFRM path does not check that a routing header's segments_left field is no larger than the number of addresses actually present, so pointer arithmetic in ipv6_rearrange_rthdr() walks out of bounds and an oversized memmove() corrupts kernel memory. It needs AH6 and XFRM support plus CAP_NET_ADMIN and CAP_NET_RAW in a namespace the attacker controls. The researcher also reports a remote crash, and in his own lab remote root, against a host acting as an IPv6 router that applies AH in transport mode.
PPPoEject (CVE-2026-68121): A use after free in pppoe_sendmsg(). The function holds a pointer into the socket buffer head across a dev_hard_header() callback that can reallocate that head, then writes six bytes through the stale pointer. It needs a lower device whose header callback expands the buffer head, not merely a loadable PPPoE module, which makes it the narrowest of the four in practice.
TUNderflow (CVE-2026-81000): The TUN/TAP driver stores a receive headroom value without bounding it. A device path that propagates oversized headroom (the proof of concept chains a netkit device through Open vSwitch to a raw TUN port) underflows a size calculation and leaves packet data 64 bytes past the end of the allocation. Simply having a TUN or TAP interface is not enough, you need that headroom propagation path. Worth correcting a common assumption here: Docker's default bridge networking uses veth pairs rather than TUN/TAP, and the in kernel WireGuard module is its own device type, so the usual homelab exposure is QEMU tap interfaces and OpenVPN style TUN devices, not containers.
DiagSpill (CVE-2026-74469): An SCTP association can hold up to 65,536 peer transports but the counter is 16 bits wide, so it wraps to zero at the limit. sctp_diag then reserves buffer space based on the wrapped count and copies the full transport list anyway, writing roughly 8 MiB past the end of the response buffer. This one needs no capabilities and no user namespace, only SCTP and sctp_diag support, which is what makes it the priority of the four.

DiagSpill is the one to move fastest on if you are triaging. It is the only one of the four that an ordinary local user can reach without creating a user namespace, which also means the usual advice to restrict unprivileged user namespaces does nothing for it. If you do not need SCTP, keep the module out of the kernel.

🛡️ Hardening Beyond the Patch

Patching is the fix, but a few additional controls reduce your exposure, which matters more than usual here because some distributions have not shipped all four yet. Restricting unprivileged user namespaces closes the ordinary user path to three of the four. It does nothing for DiagSpill.

Restrict unprivileged user namespaces: Three of these four bugs need a user namespace for an ordinary local user to reach them. Ubuntu introduced AppArmor based restrictions in 23.10 and enabled them by default from 24.04, controlled by kernel.apparmor_restrict_unprivileged_userns, so 24.04 and 26.04 are covered out of the box. Debian is not. The Debian and Ubuntu specific kernel.unprivileged_userns_clone knob has been discussed for deprecation, so confirm it exists on your kernel with sysctl -a | grep userns before relying on it; the portable upstream equivalent is sysctl -w user.max_user_namespaces=0. Either way you will break things that legitimately use user namespaces, including Flatpak, rootless containers and browser sandboxes.
Use AppArmor or SELinux profiles: Proxmox ships with AppArmor. Make sure it is enforcing for your LXC containers. Unprivileged containers with AppArmor confinement are significantly harder to break out of.
Limit local access: Do not run untrusted code or expose shell access to untrusted users on these nodes. Local privesc only matters if someone or something local can trigger it.
Unload unused kernel modules: If you are not using PPPoE or SCTP, keep both out. Add blacklist pppoe and blacklist sctp to a file in /etc/modprobe.d/ and run update-initramfs -u. Blacklisting stops the on demand autoload that a socket call would trigger, and for DiagSpill that is the only mitigation short of patching, since restricting user namespaces does not touch it. Verify with lsmod | grep -E 'pppoe|sctp' afterwards.

🔧 Troubleshooting

Kernel version did not change after reboot: Your package manager may have the patched package available but it was not installed. Run apt list --upgradable | grep linux-image to check, then install explicitly with sudo apt install linux-image-[version] matching your architecture.

Proxmox node is stuck on an older kernel: Proxmox sometimes pins the kernel for stability. Check /etc/default/grub and the GRUB menu to ensure the new kernel is selected as default. Run update-grub after confirming the package is installed.

Raspberry Pi will not boot after upgrade: This is rare but can happen if the bootloader and kernel fall out of sync. Boot from a backup SD card or use rpi-update with caution, and check the Raspberry Pi OS forums for your specific board and OS version before using it.

✅ Wrap Up

Four local root bugs in one disclosure batch is a bad day for Linux security. Updating and rebooting is the right move, but as of 29 September 2026 it is not the whole answer: Debian trixie has all four, Debian bookworm is still missing the TUNderflow fix, and Ubuntu has not released kernels for any of them. Prioritize DiagSpill, since it is the one an unprivileged local user can reach without a user namespace, and check the tracker for your distribution instead of assuming a fresh upgrade covered you.

After you patch, take five minutes to check your other nodes. It is easy to forget a Raspberry Pi tucked behind the TV or a secondary Proxmox node you set up months ago. Cross-reference the patched kernel version against your distro's security tracker to make sure you are actually covered, not just up to date on packages.

Stay subscribed to oss-sec if you want these disclosures in your inbox before they make the rounds on aggregators.

KVM vs KVM - what is the question?

Tue, 28 Jul 2026 22:04:05 +0000

Last weekend I was looking for a new project for my Raspberry Pi. I was looking for ways to set up a KVM on my Pi5 since it has 8GB of RAM, which is beefy enough for additional virtualisation tasks. Once I started Googling how I should start this task, I would look up “KVM on Raspberry Pi”. Most of the search results were for another entirely different KVM.

A Keyboard, Video, and Mouse (KVM) switch is a hardware device that allows a user to control multiple computers or servers using a single set of keyboard, video display, and mouse devices. While the KVM switch is a great technology that allows you to control multiple computers using your existing setup, I currently use Tailscale for accessing my remote Pis via my home laptop. So that wasn’t what I was looking for. Instead, I was interested in seeing whether I could run a Kernel Virtual Machine (KVM) on my Pi5.

Despite sharing the same acronym, a KVM switch and the KVM software operate in entirely different realms of technology: one is a physical hardware device for managing physical computers, while the other is open-source software built into Linux to create and manage virtual machines. The KVM Switch routes peripheral and display signals between different systems with the press of a button or a keyboard shortcut.

What is a KVM VM?

Kernel-based VM is an open source virtualisation technology for Linux. With KVM, Linux can function as a hypervisor that runs multiple, isolated VMs. KVM was announced way back in 2006 and actually merged into the Linux kernel in 2007. Virtualisation, which lets you run an operating OS inside another OS, is possible thanks to hypervisors.

A hypervisor pools computing resources (like processing, memory, and storage) and reallocates them among VMs. The hypervisor can run multiple VMs at once, manage them, and support the creation of new ones. The physical hardware, when used as a hypervisor, is called the host, while the many VMs that use its resources are guests. Hypervisors need OS-level components such as memory management, process scheduling, I/O, device drivers, security management, a network stack, and more to run VMs.

KVM has all these components because it’s part of the Linux kernel. Every VM is implemented as a regular Linux process, scheduled by the standard Linux scheduler, with dedicated virtual hardware like a network card, graphics adapter, CPU, memory, and disks.

Similarities between KVM and KVM

Both technologies fundamentally exist to solve an efficiency problem: enabling a user to manage multiple OSs from a single workstation without buying duplicate input devices or displays. Whether toggling between two physical tower PCs or switching focus between multiple virtual instances, both implementations allow one operator to interact with distinct, isolated computing environments. Furthermore, both solutions preserve system isolation, ensuring that actions taken within one environment do not interfere with or crash the other operating systems running alongside it.

Differences

The key distinction lies in hardware physical routing versus software virtualisation. A KVM switch is a tangible piece of hardware that physically redirects signal cables (HDMI/DisplayPort and USB) so that a single set of peripherals can control multiple physically distinct servers or PCs. It does not alter how the computers operate; it merely changes which machine receives your keypresses and sends video output to your monitor.

In contrast, a Kernel-based VM is a software module integrated directly into the Linux kernel that turns the host OS into a Type-1 hypervisor. Instead of connecting separate physical machines, the kernel-based KVM partitions a single computer's underlying processor, memory, and storage to simulate entirely separate virtual computers (Guest VMs) on the same bare metal.

The question should’ve been KVM or Xen?

And that brings us to a totally different question. KVM and Xen - what are the differences and which one can I run on my Pi5 for virtualisation? While both KVM and Xen are open-source Type-1 hypervisors that deliver high-performance virtualisation, their core designs and operational structures differ significantly.

KVM is built directly into the Linux kernel as a standard kernel module (kvm.ko). Installing KVM turns an existing Linux OS into a hypervisor, granting you immediate access to standard Linux drivers, process schedulers, and existing system management tools without having to modify the host kernel. Conversely, Xen sits below the OS as a microkernel-based layer that boots first, before any OS. It relies on a special, privileged Guest VM known as Dom0 (Domain 0) to handle hardware access, boot management, and admin control over other Guest VMs (DomU).

KVM relies purely on hardware-assisted virtualisation (using processor extensions like Intel VT-x or ARM Virtualisation Extensions) to run unmodified Guest OSs. Xen historically pioneered paravirtualisation (where guest kernels are modified to communicate directly with the hypervisor API for higher efficiency), though it now supports hardware-assisted virtualisation as well. Furthermore, Xen’s strict separation of the hypervisor microkernel from the control domain (Dom0) isolates hardware drivers away from guest VMs, which makes it a popular architecture for high-security environments like Qubes OS.

For almost all Raspberry Pi 5 use cases, KVM is the far more practical and seamless option.

In the case of the Raspberry Pi, you’ll need to verify hardware virtualisation support before doing anything. Check that ARM CPU virtualisation extensions are available. Check that the KVM hypervisor kernel module is present and accessible with the below command:

ls -l /dev/kvm

You should see an output showing crw-rw---- 1 root kvm ... /dev/kvm.
If /dev/kvm exists, hardware acceleration is supported and active.

The Raspberry Pi’s boot process relies on a proprietary EEPROM-based bootloader that loads GPU firmware and kernel binaries directly from an SD card or NVMe storage (often chainloaded through U-Boot for standard Linux environments). Because KVM is integrated into standard ARM64 Linux kernels (like Raspberry Pi OS 64-bit or Ubuntu), it requires no special bootloader tweaks or UEFI emulation layer. You simply install `qemu-kvm` (QEMU) and libvirt, and the Pi instantly acts as a hypervisor using built-in ARM hardware extensions, allowing me to easily spin up VMs using standard Linux tools like virt-manager or cockpit.

You can run the following command to install the hypervisor, daemon services, and CLI management tools like QEMU core binaries. Since I’m running Raspberry Pi OS Desktop with the graphical interface, I also appended virt-manager to the below command:

sudo apt install -y qemu-system-arm qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virtinst virt-manager

Once the packages are installed, I just need to startup/enable the libvirtd service to ensure the hypervisor daemon starts automatically on boot:

sudo systemctl enable --now libvirtd

Libvirt includes a default NAT network interface (virbr0) for guest VMs. As soon as the default virtual network was configured, I can simply create my first Guest VM on the Pi5 and use an Ubuntu ARM64 ISO image, sourced from the Canonical website. The virt-install looks a little like this:

virt-install \
  --name debian-vm \
  --memory 2048 \
  --vcpus 2 \
  --disk size=10,bus=virtio \
  --os-variant debian12 \
  --cdrom /path/to/debian-arm64.iso \
  --network network=default \
  --graphics vnc,listen=0.0.0.0

In contrast, setting up Xen on a Pi 5 requires a complex boot architecture. Because Xen acts as a microkernel that must load before any OS, booting it on an SBC (Single Board Computer) generally requires using U-Boot to load the Xen binary alongside device-tree overlays, a customised Dom0 control domain, and a secondary driver domain. While projects like Xen-Troops exist specifically to compile custom Yocto-based Xen images for embedded systems and automotive apps, setting this up for home or homelab experiments involves significant compilation overhead, non-standard driver configs, and manual partition setups. While maybe not suited to Pi5, it’s not impossible on previous versions like the Pi4, as stated on the Linux blog. For edge use-cases you can certainly stick with KVM for a smooth setup unless you specifically need Xen's compartmentalised driver architecture for complex embedded development. If you’d like to read why Edera specifically opted for Xen when building a secure microservice foundation, check out their blog post.

How to Detect and Monitor Multiple GPUs on Linux

Sun, 15 Mar 2026 00:22:28 +0000

If you run Linux on a system with both an integrated GPU and a dedicated GPU, you may have noticed something strange: some monitoring tools only show one GPU.

This situation is common on:

laptops with hybrid graphics
desktops with iGPU + dedicated GPU
systems using different driver stacks

For example, a monitoring tool like btop might show your AMD integrated GPU but completely ignore your NVIDIA card.

In this article we will walk through how to:

detect all GPUs installed in your system
verify that the correct drivers are loaded
identify which GPU is rendering your desktop
monitor usage for each GPU
automate the entire diagnostic process with a small script

Why This Happens

Linux systems with multiple GPUs may behave differently depending on:

installed drivers (open source vs proprietary)
kernel configuration
which GPU is configured as the primary renderer
monitoring tool capabilities

Example setup used in this article:

AMD Vega (integrated) — Ryzen 5 5600G
NVIDIA GTX 1050 Ti (dedicated)

In this configuration, btop showed only the AMD GPU while the NVIDIA card remained invisible in the default monitoring view.

Step 1 — Check if Both GPUs Are Detected

1.1 List GPUs via PCI

Run:

lspci | grep -i vga

Example output:

01:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti]
09:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series]

If two entries appear, your hardware is being detected correctly.

1.2 Check Loaded Drivers

Run:

lsmod | grep -E 'nvidia|amdgpu|radeon'

Typical modules:

GPU	Kernel Module
NVIDIA	`nvidia`, `nvidia_drm`, `nvidia_modeset`
AMD (modern)	`amdgpu`
AMD (legacy)	`radeon`

If the modules appear, the drivers are loaded by the kernel.

1.3 Check Which GPU Is Rendering Your Desktop

Use:

glxinfo | grep "OpenGL renderer"

Example output:

OpenGL renderer string: NVIDIA GeForce GTX 1050 Ti

If glxinfo is missing, install it.

Ubuntu / Debian:

sudo apt install mesa-utils

Arch Linux:

sudo pacman -S mesa-utils

This command reveals which GPU is rendering the graphical session.

In hybrid setups, the integrated GPU often renders the desktop while the dedicated GPU activates only for demanding workloads.

Step 2 — Monitoring Each GPU

2.1 Integrated GPU (AMD / Intel) — Using btop

Launch:

btop

Inside btop:

press g to toggle GPU views
press 5 / 6 / 7 for specific GPU panels
configure via F2 → Options → CPU box → Show GPU info

2.2 NVIDIA Dedicated GPU — Using nvidia-smi

For NVIDIA GPUs the official tool is the most reliable:

watch -n 1 nvidia-smi

This updates every second and displays:

GPU utilization
memory usage
running processes

Structured output:

nvidia-smi --query-gpu=name,memory.used,memory.total,utilization.gpu --format=csv -l 1

Step 3 — Automating GPU Diagnostics

Create a script called:

check_gpus.sh

Script:

#!/bin/bash

echo "=== GPUs Detected ==="
lspci | grep -E "VGA|3D"

echo -e "\n=== Loaded Drivers ==="
lsmod | grep -E "nvidia|amdgpu|radeon"

echo -e "\n=== NVIDIA GPU ==="
nvidia-smi --query-gpu=name,memory.total --format=csv 2>/dev/null || echo "NVIDIA not detected"

echo -e "\n=== Rendering GPU ==="
glxinfo | grep "OpenGL renderer" 2>/dev/null || echo "glxinfo not available"

echo -e "\n=== DRM Devices ==="
ls /sys/class/drm | grep card

Make executable:

chmod +x check_gpus.sh

Run:

./check_gpus.sh

This quickly shows:

detected GPUs
active drivers
rendering GPU
NVIDIA status
DRM device nodes

Recommended Tools Summary

GPU Type	Recommended Tool	Command
AMD / Intel (integrated)	`btop`	`btop`
NVIDIA (dedicated)	`nvidia-smi`	`watch -n 1 nvidia-smi`
Hardware detection	`lspci`	`lspci \| grep -i vga`
Rendering check	`glxinfo`	`glxinfo \| grep "OpenGL renderer"`

Conclusion

Working with multiple GPUs on Linux doesn't have to be confusing.

Using the commands shown above you can:

verify hardware detection
confirm driver loading
identify which GPU renders your desktop
monitor GPU usage in real time
automate diagnostics with a small script

Different GPU stacks require different tools, but combining a few commands provides full visibility into your graphics subsystem.

Additional Resources

btop documentation
https://github.com/aristocratos/btop

NVIDIA System Management Interface
https://developer.nvidia.com/nvidia-system-management-interface

Arch Linux Wiki — NVIDIA
https://wiki.archlinux.org/title/NVIDIA

Unlocking the Power of Linux Device Drivers

Sun, 03 Nov 2024 21:33:35 +0000

Introduction

Linux is a versatile and widely-used operating system, from enterprise servers to embedded systems. At the heart of its functionality is the ability to interact with hardware, which is made possible by device drivers. These drivers are specialized software that facilitate communication between the operating system and hardware, enabling the OS to manage peripherals efficiently.

In this blog, we will delve into the world of Linux device drivers, discussing their architecture, types, security concerns, and how to develop simple drivers for character and block devices with practical examples.

1. What is a Device Driver?

A device driver is software that enables communication between the operating system and hardware. It acts as an intermediary, allowing user applications to access hardware components like storage devices, network interfaces, and peripherals. Without device drivers, the OS would not be able to control or communicate with hardware efficiently.

Key Functions of a Device Driver:

Configuration: Initializes and configures hardware components.
Data Transfer: Manages read and write operations between the OS and the hardware.
Request Handling: Processes commands from the OS and hardware interrupts.
Interface Provisioning: Provides standardized interfaces to user-space applications for communication with hardware.

2. Types of Device Drivers in Linux

Linux drivers are categorized based on the type of hardware they control:

a. Character Device Drivers

Character devices, like serial ports, sensors, and keyboards, transfer data sequentially as a stream of bytes. The driver provides basic operations like read(), write(), and ioctl() to interact with the device.

b. Block Device Drivers

Block devices, such as hard drives and USB storage, operate by reading and writing data in blocks. Block drivers enable random access to data, and they interface with the Linux file system and I/O subsystems.

c. Network Device Drivers

Network devices, such as Ethernet and Wi-Fi adapters, transmit and receive packets. Network drivers must handle packet transmission and reception through functions like ndo_start_xmit() for sending packets and interrupt handling for receiving packets.

3. Kernel Space, User Space, and Security

Kernel Space

Kernel space is where the Linux kernel operates, with full access to system resources and hardware. Drivers, which reside in kernel space, can directly manage hardware and system memory. Because kernel code runs with high privileges, a bug in the driver can crash the system or expose it to security vulnerabilities.

User Space

User space is where user applications run, with restricted access to system resources. To communicate with the kernel (and device drivers), user programs make system calls such as open(), read(), and write(). These calls allow user-space applications to interact indirectly with hardware through the device drivers.

4. Linux Device Driver Architecture

The architecture of Linux device drivers revolves around the following components:

Driver Initialization: When a driver is loaded into the kernel, it registers itself with the kernel, associating its functions with specific devices.
Handling User Requests: The driver exposes system calls to user-space applications, which can interact with hardware devices through the driver.
Interrupt Handling: Drivers register interrupt handlers to respond to hardware interrupts, enabling efficient asynchronous communication.
Direct Memory Access (DMA): Some drivers use DMA to facilitate data transfer between devices and memory without involving the CPU, optimizing performance.

5. Security Considerations in Device Driver Development

Device drivers operate at a critical layer of the system and are often a target for attacks. This section explores some common security concerns when developing Linux device drivers and best practices to mitigate these risks.

a. Buffer Overflows

Buffer overflows occur when a driver writes more data to a buffer than it can hold, causing data to overwrite adjacent memory. This can lead to unpredictable behavior, system crashes, or even code execution. For example, when handling user inputs in the write() function, the driver must check the length of the data to ensure it doesn't exceed the allocated buffer size.

Solution:

Always validate the size of input data.
Use safe memory handling functions such as copy_from_user() and copy_to_user() to transfer data between kernel space and user space.

b. Race Conditions

Race conditions happen when multiple processes try to access or modify shared resources concurrently without proper synchronization, leading to unpredictable system behavior. In drivers, this often involves interrupt handlers and user-space requests that share the same data structures.

Solution:

Use kernel synchronization primitives like spinlocks, mutexes, and semaphores to ensure consistent access to shared resources.
Carefully design interrupt handlers to prevent race conditions.

c. Privilege Escalation

Since device drivers run in kernel space, a bug or vulnerability in a driver can allow an attacker to execute arbitrary code with elevated privileges. For example, if a driver improperly validates user input, malicious code can trigger unintended behavior, leading to a system compromise.

Solution:

Always validate inputs from user space.
Ensure drivers operate with the least privileges necessary to perform their tasks.
Implement access control mechanisms to restrict who can interact with the driver.

d. Denial of Service (DoS) Attacks

A poorly written driver can be exploited to cause a denial of service by overwhelming system resources (e.g., flooding the driver with requests or triggering infinite loops). This can crash the system or degrade performance.

Solution:

Implement robust error handling and input validation to avoid scenarios where the driver can be overwhelmed.
Use timeouts and limits to prevent resource exhaustion.

e. Memory Leaks

Memory leaks occur when a driver allocates memory but fails to release it after use. Over time, this can exhaust system memory, causing the kernel to run out of resources.

Solution:

Ensure that all allocated memory is properly released when no longer needed, especially when the driver is unloaded.
Regularly test drivers using tools like kmemleak to detect memory leaks.

6. Writing a Simple Character Device Driver

A character device driver handles devices like serial ports that send and receive data as a stream of bytes. Below is an example of a simple character device driver that can be loaded as a kernel module.

Example: Simple Character Device Driver

#include <linux/module.h>
#include <linux/fs.h>
#include <linux/uaccess.h>

#define DEVICE_NAME "simple_char_dev"
#define BUF_LEN 80

static char msg[BUF_LEN]; // Buffer to hold the data

// Function prototypes for character driver
static int device_open(struct inode *, struct file *);
static int device_release(struct inode *, struct file *);
static ssize_t device_read(struct file *, char *, size_t, loff_t *);
static ssize_t device_write(struct file *, const char *, size_t, loff_t *);

// File operations structure
static struct file_operations fops = {
    .read = device_read,
    .write = device_write,
    .open = device_open,
    .release = device_release,
};

static int major_num;

// Driver initialization function
static int __init simple_char_init(void) {
    major_num = register_chrdev(0, DEVICE_NAME, &fops);
    if (major_num < 0) {
        printk(KERN_ALERT "Failed to register character device\n");
        return major_num;
    }
    printk(KERN_INFO "Simple char driver loaded with major number %d\n", major_num);
    return 0;
}

// Driver cleanup function
static void __exit simple_char_exit(void) {
    unregister_chrdev(major_num, DEVICE_NAME);
    printk(KERN_INFO "Simple char driver unloaded\n");
}

static int device_open(struct inode *inode, struct file *file) {
    printk(KERN_INFO "Device opened\n");
    return 0;
}

static ssize_t device_read(struct file *filp, char *buffer, size_t len, loff_t *offset) {
    int bytes_read = 0;
    if (*msg == 0)
        return 0;
    while (len && *msg) {
        put_user(*(msg++), buffer++);
        len--;
        bytes_read++;
    }
    return bytes_read;
}

static ssize_t device_write(struct file *filp, const char *buffer, size_t len, loff_t *off) {
    int i;
    for (i = 0; i < len && i < BUF_LEN; i++)
        get_user(msg[i], buffer + i);
    return i;
}

static int device_release(struct inode *inode, struct file *file) {
    printk(KERN_INFO "Device closed\n");
    return 0;
}

module_init(simple_char_init);
module_exit(simple_char_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Author");
MODULE_DESCRIPTION("Simple Character Device Driver");

This example demonstrates how to implement basic operations (open(), read(), write(), and release()) for a character device. It can be compiled as a loadable kernel module and communicates with user-space applications via /dev.

Security tip: Always validate the size of incoming data to prevent buffer overflow attacks, as shown in the device_write() function.

7. Writing a Simple Block Device Driver

A block device driver manages devices like hard drives that perform I/O in blocks of data. Block drivers typically interface with the file system and handle requests from the kernel's block layer.

To write a simple block device driver, you would:

Register the block device with the kernel.
Set up request queues for managing I/O requests.
Handle data read and write operations in blocks, managing memory appropriately.

Block device drivers must also handle interrupts and use Direct Memory Access (DMA) for efficient data transfer. Proper error handling is critical to ensure data integrity.

8. Network Device Drivers

Network device drivers manage devices like Ethernet and Wi-Fi adapters. They are responsible for packet transmission and reception, interfacing with the Linux network stack.

Security Considerations in Network Drivers:

Input Validation: Ensure that packet sizes and formats are properly validated to prevent buffer overflow and packet injection attacks.
Rate Limiting: Implement mechanisms to prevent flooding attacks, which can exhaust system resources.
Access Control: Restrict which processes and users can send and receive network packets to prevent unauthorized network access.

9. Conclusion

Linux device drivers are essential to the functionality of the OS, enabling it to interact with hardware efficiently. In this blog, we covered the different types of Linux device drivers, kernel space vs. user space, and the security challenges that arise during driver development. With the example of a simple character driver, you now have a basic understanding of how drivers operate.

The security of device drivers is paramount, as they run in kernel space with high privileges. By adhering to best practices such as input validation, memory management, and proper error handling, developers can build secure and efficient drivers that protect the system from potential vulnerabilities.

Coder Legion - Recent posts tagged kernel

Patch These Four Linux Kernel Local Root Vulns Now: DirtyAH6, PPPoEject, TUNderflow, and DiagSpill

💡 Why This Matters for Homelabbers

🧰 Prerequisites

🔧 Step-by-Step: Patching Your Nodes

🛡️ Patch Status, Checked 29 September 2026

🛡️ What Each Vulnerability Affects

🛡️ Hardening Beyond the Patch

🔧 Troubleshooting

✅ Wrap Up

Related from the lab

KVM vs KVM - what is the question?

What is a KVM VM?

Similarities between KVM and KVM

Differences

The question should’ve been KVM or Xen?

How to Detect and Monitor Multiple GPUs on Linux

Why This Happens

Step 1 — Check if Both GPUs Are Detected

1.1 List GPUs via PCI

1.2 Check Loaded Drivers

1.3 Check Which GPU Is Rendering Your Desktop

Step 2 — Monitoring Each GPU

2.1 Integrated GPU (AMD / Intel) — Using btop

2.2 NVIDIA Dedicated GPU — Using nvidia-smi

Step 3 — Automating GPU Diagnostics

Recommended Tools Summary

Conclusion

Additional Resources

Unlocking the Power of Linux Device Drivers

Introduction

1. What is a Device Driver?

Key Functions of a Device Driver:

2. Types of Device Drivers in Linux

a. Character Device Drivers

b. Block Device Drivers

c. Network Device Drivers

3. Kernel Space, User Space, and Security

Kernel Space

User Space

4. Linux Device Driver Architecture

5. Security Considerations in Device Driver Development

a. Buffer Overflows

Solution:

b. Race Conditions

Solution:

c. Privilege Escalation

Solution:

d. Denial of Service (DoS) Attacks

Solution:

e. Memory Leaks

Solution:

6. Writing a Simple Character Device Driver

Example: Simple Character Device Driver

7. Writing a Simple Block Device Driver

8. Network Device Drivers

Security Considerations in Network Drivers:

9. Conclusion