Kernel code removals driven by LLM-created security reports

Reasons for kernel code removal

• Many removed subsystems are effectively unmaintained: few or no familiar developers, fixes driven almost entirely by static analysis, and unclear real-world users.
• LLM-generated security reports dramatically increased the volume of bugs found in this old code, forcing maintainers to either own it or drop it.
• Unmaintained kernel code is framed as technical debt and a concrete security risk in a 2026 threat environment, especially for local privilege-escalation vectors via obscure drivers.
• Some see this as “tree shaking” of the kernel: rarely used modules get pushed out, reducing attack surface for everyone else.

Legacy hardware and niche use cases

• Debate over whether technologies like ISDN and AX.25 are still used:
  • One side claims telco retirement and IP migration make them effectively dead.
  • Others cite continued use in broadcasting, voiceover work, ham radio, industrial systems, and low‑bandwidth sensor links.
• Concerns that niche users (industrial PCI capture cards, old NICs, HAM protocols) are “completely broken” when support disappears.
• Suggestions:
  • Move such drivers out-of-tree or into separate module trees.
  • Have a “hobbyist kernel” or clear “unmaintained/insecure” config flags.
  • Counterpoint: Linux’s unstable in-kernel driver APIs make out-of-tree maintenance painful.

LLMs as vulnerability finders

• Some argue modern LLMs are now very effective for legacy C security:
  • Large numbers of real bugs found in major projects (e.g., Firefox, kernels, curl), especially classic memory-safety issues.
  • They scale cheaply across huge codebases; humans previously “weren’t looking” in many places.
• Others emphasize:
  • High false-positive rates, hallucinations, and need for skilled human triage.
  • Risk of spammy, low-quality reports from users overconfident in LLM output.
• Consensus elements:
  • LLMs are useful amplifiers for professional security work and exploit development.
  • They do not eliminate the need for expert reviewers.

Security, architecture, and philosophy

• Broad agreement that “code is attack surface”; reducing kernel complexity is good.
• Strong push toward moving protocol/stateful logic (e.g., network stacks, HAM protocols) into userspace daemons; some see this as belated validation of microkernel ideas.
• Disagreement over performance costs of userspace networking and whether they matter for very slow links like AX.25.
• Philosophical split:
  • One camp prioritizes security and maintainability, accepting removal and “won’t fix.”
  • Another prioritizes longevity and reuse of old hardware, seeing Linux as drifting toward corporate/PR priorities and increasing e‑waste.