The Linux IOCTL Census: A Source-Derived Database of the Linux Kernel Control-Code Surface

Technical Summary: The Linux IOCTL Census

Problem Statement
The ioctl system call serves as Linux's primary interface for device control, allowing userspace programs to send numeric command codes and argument buffers to kernel drivers. While essential for hardware configuration and state management, this interface represents a vast, heterogeneous, and poorly cataloged local attack surface. Drivers define thousands of unique commands, often parsing arguments in kernel context without uniform validation. A handler that trusts an unvalidated argument length can lead to out-of-bounds memory reads or writes.

Current approaches to analyzing this surface are fragmented:

• Dynamic Scanners (e.g., syzkaller): Effective at finding runtime bugs and race conditions but limited to the specific command space they are explicitly told to exercise. They report triggered bugs, not the unexplored command space.
• Manual Curation: Lists like the unprivileged-reach LPE catalogue and threat-model documentation exist but are hand-kept prose, not systematic, queryable enumerations of the decoded command space.

There is a lack of a persistent, source-derived inventory that maps the entire static command surface, including dispatchers, decoded commands, handlers, and permission gates.

Methodology: Extract-Gate-Rank
The authors present a deterministic pipeline, Extract-Gate-Rank, which reads the Linux kernel source code to materialize a relational database of the ioctl surface. The process operates on an allmodconfig build (x86_64) covering 878 modules across 169 subtrees.

1. Extract:

   • Utilizes a libclang-derived knowledge graph from the kernel source to identify ioctl dispatchers (functions bound to unlocked_ioctl, compat_ioctl, or proc_ops.proc_ioctl).
   • Walks call closures to per-command handler bodies.
   • Decodes Command Codes: A resolver expands _IOC macros against UAPI headers to decode 32-bit command codes into four fields: direction, size, magic byte, and ordinal.
   • Identifies Sinks and Gates: Records controlled-input sinks (e.g., copy_from_user) within a fixed call-hop window and permission gates (capability checks, LSM hooks, f_mode checks).
   • Sanitization Heuristic: Marks a sink as "unsanitized" if no preceding hard bounds check exists in the same function source order. This is a structural proxy, not a control-flow proof.

2. Gate:

   • Applies a threat-model reachability filter as a queryable column.
   • A module is marked capability_ungated if its ioctl path lacks a hard init-namespace capability gate (e.g., CAP_SYS_ADMIN).
   • This acts as a necessary-condition upper bound on unprivileged reach, not a classifier of actual node-openability. It excludes staging drivers and debugfs paths per kernel documentation.

3. Rank:

   • Generates relational views over the store, prioritizing capability-ungated dispatchers with unsanitized sinks.
   • Includes a cross-module view grouping shared command codes (type, ordinal, access) across different drivers.
   • An optional LLM enrichment layer is included for triage but is kept off the critical path and in a withheld tier.

Key Results
The census covers the x86_64 allmodconfig build (84% of in-tree source files) and includes a secondary arm64 build for validation.

• Scale: The analysis recovered 586 ioctl dispatch entry points across 337 modules, decoding 1,289 unique _IOC command codes.
• Sinks and Gates: It identified 3,583 controlled-input sinks and 1,298 permission gates.
• Reachability: The threat-model filter excluded 50 modules behind hard capability gates, admitting 281 modules as the capability-ungated upper bound on unprivileged reach.
• Architecture Coverage: A second build for arm64 added only one unique module (Apple adp_drv) and no new command codes, indicating x86_64 covers 99.7% of the ioctl-bearing modules.
• Command Sharing: Shared command patterns (e.g., watchdog WDIOC_* commands) recur across multiple drivers, suggesting that a vulnerability in a shared pattern could affect many modules simultaneously.
• Capability Concentration: Permission gates are dominated by CAP_SYS_ADMIN (512 occurrences), a capability the kernel threat model explicitly treats as "out of model," further narrowing the in-scope attack surface.

Backtest Validation
The authors validated the census against 22 recent in-tree ioctl CVEs:

• Coverage: All 22 CVEs fell within covered subtrees, eliminating coverage gaps as a source of error.
• Recovery: The dispatcher-recovery pass found the vulnerable handler for 7 of the 22 CVEs.
• Misses: The 15 misses were entirely attributable to registration model limitations:
  • 8 cases involved DRM/V4L2 cores using ops-table dispatch (drm_ioctl_desc, v4l2_ioctl_ops) where the core copies arguments before passing them to per-command handlers.
  • 3 cases involved tty line disciplines.
  • 4 cases were functions reached only as callees below the dispatcher switch, not the dispatcher itself.
• Filter Accuracy: The filter correctly admitted all 7 found CVEs. Two were "false admits" regarding node-DAC (Device Access Control) restrictions (e.g., pci_endpoint_test), which the method correctly predicts as a limitation since it does not analyze device node permissions, only capability gates.

Significance and Claims
The paper positions the Linux IOCTL Census as a measurement and dataset contribution rather than a bug-finding tool. Its primary significance lies in:

1. Persistence and Queryability: It transforms the ioctl surface from a transient list of bugs into a persistent, queryable relational store. This allows auditors to ask structural questions (e.g., "Which modules share this command code?") that bug lists cannot answer.
2. Threat-Model Integration: It encodes the kernel's documented threat model directly into the data schema, turning prose-based security boundaries into queryable filters.
3. Complementarity: It complements dynamic fuzzing by enumerating the entire static command space, including commands that may lack harnesses or descriptions, thereby guiding dynamic tools toward unexplored areas.
4. Cross-OS Schema: The dataset shares a schema with the companion Windows IOCTL Census, enabling cross-platform queries.

Limitations
The authors explicitly state several bounds:

• Reachability: The "user-reachable" count is an upper bound based on capability gates, not a proof of node-openability (DAC).
• Sanitization: The "unsanitized" count is a heuristic proxy based on source order, not a formal proof of safety.
• Coverage: It is limited to what an allmodconfig build compiles; other architectures and drivers that cannot be co-enabled are excluded.
• Registration Model: The current model misses handlers registered via ops-tables (DRM, V4L2, ALSA), tty line disciplines, and helper functions below the dispatcher.

The dataset is released in two tiers: a public structural tier (modules, dispatchers, codes, gates) under an open license, and a withheld targeting tier (specific sink locations, enrichment verdicts, and ranked unprivileged surface) to prevent dual-use exploitation while supporting authorized research.