grsecurity - The Complicated History of a Simple Linux Kernel API

submited by

Style Pass

2021-06-30 02:00:08

Luo Likang of NSFOCUS posted to the oss-sec mailing list about what he was told was a non-security bug in the Linux kernel's Common Field replaceable unit Access Macro (CFAM) device driver. While the bug itself is uninteresting (it would at most be a privileged DoS on some PowerPC systems under a non-standard config), this blog will discuss the nuance and history of bad sizes passed to the kernel's copy_*_user() API based on our two decades of kernel development experience. A seemingly simple topic at first glance, but we guarantee readers of any kernel development skill level will learn something new here.

The Linux kernel is a constantly evolving codebase with well over 30 million lines of code as of 2021. As users generally don't run the latest upstream Linux kernel, however, it's also a very fragmented codebase from a user perspective. This has important ramifications for security: it's not necessarily the case that someone can say (as apparently happened in this case) that an API like copy_from_user() has certain checks, and that those checks can prevent triggering a vulnerability. I specifically addressed this issue in my "10 Years of Linux Security - A Report Card" presentation from last year. Consistent security properties (across kernel versions, processor architectures, compiler versions) is an important goal of ours in grsecurity, but with upstream often not backporting added preventative security checks or functionality to older supported kernels, and with the state of those measures not being communicated to end-users, one would virtually have to be an experienced security-focused kernel developer to determine the status for their own systems.

The kinds of bugs affected by checks in copy_*_user have appeared several times in the past, see for instance this fix from Mathias Krause in 2013. When discussing these checks, it would make most sense to talk about the current upstream state, after which we can discuss the history of the code and how it evolved (and even devolved) over time.