Linux Kernel Monkey Log

As described previously, the Linux kernel security team does not identify or mark or announce any sort of security fixes that are made to the Linux kernel tree.

Lots of the CVE world seems to focus on “security bugs” but I’ve found that it is not all that well known exactly how the Linux kernel security process works.

With all of the different Linux kernel stable releases happening (at least 1 stable branch and multiple longterm branches are active at any one point in time), keeping track of what commits are already applied to what branch, and what branch specific fixes

Despite having a stable release model and cadence since December 2003, Linux kernel version numbers seem to baffle and confuse those that run across them, causing numerous groups to mistakenly make versioning statements that are flat out false.

It’s been almost 2 full years since Linux became a CNA (Certificate Numbering Authority) which meant that we (i.e. the kernel.org community) are now responsible for issuing all CVEs for the Linux kernel.

…the one that emulates your real workload.

As was recently announced, the Linux kernel project has been accepted as a CNA as a CVE Numbering Authority (CNA) for vulnerabilities found in Linux.

Greg is a Fellow at the Linux Foundation and is responsible for the Linux kernel stable releases.

As was pointed out to us stable kernel maintainers last week, the overflow of the .y release number was going to happen soon, and our proposed solution for it (use 16 bits instead of 8), turns out to be breaking a userspace-visable api.

A recent email thread about “Why isn’t the 5.10 stable kernel listed as supported for 6 years yet!”

A number of months ago I did an “Ask Me Anything” interview on r/linux on redit.

Given that the main development workflow for most kernel maintainers is with email, I spend a lot of time in my email client.

As everyone seems to like to put kernel trees up on github for random projects (based on the crazy notifications I get all the time), I figured it was time to put up a semi-official mirror of all of the stable kernel releases on github.com It can be found…

I get a lot of questions about people asking me about what stable kernel should they be using for their product/device/laptop/server/etc. all the time.

As many people know, last week there was a court hearing in the Geniatech vs.

Note This post is based on a whitepaper I wrote at the beginning of 2016 to be used to help many different companies understand the Linux kernel release model and encourage them to start taking the LTS stable updates more often.

I keep getting a lot of private emails about my previous post about the latest status of the Linux kernel patches to resolve both the Meltdown and Spectre issues.

By now, everyone knows that something “big” just got announced regarding computer security.

Based on the recent Linux Kernel Community Enforcement Statement and the article describing the background and what it means , here are some Questions/Answers to help clear things up.

By Greg Kroah-Hartman, Chris Mason, Rik van Riel, Shuah Khan, and Grant Likely The Linux kernel ecosystem of developers, companies and users has been wildly successful by any measure over the last couple decades.

As the 4.13 release has now happened, the merge window for the 4.14 kernel release is now open.

As I briefly mentioned a few weeks ago on my G+ page, the plan is for the 4.9 Linux kernel release to be the next “Long Term Supported” (LTS) kernel.

Now that linux.conf.au is over, there has been a bunch of information running around about the status of kdbus and the integration of it with systemd.

Sometimes you don’t have access to vim’s wonderful xxd tool, and you need to use it to generate some .c code based on a binary file.

Now that The Linux Foundation is a member of the UEFI.org group, I’ve been working on the procedures for how to boot a self-signed Linux kernel on a platform so that you do not have to rely on any external signing authority.

As I’ve discussed in the past, I will be selecting one “longterm stable” kernel release every year, and maintain that kernel release for at least two years.

While working on the latest statistics for the yearly Linux Foundation “Who Writes Linux” paper, I noticed the rate-of-change for the 3.10 kernel release that just happened this weekend: Every year I think we can’t go faster, and every year I’m wrong.

One common Linux kernel driver issue that I see all the time is a driver author attempting to create a sysfs file in their code by doing something like: int my_driver_probe(...) { ...

Here’s some thoughts about some hardware I was going to use, hardware I use daily, and hardware I’ll probably use someday in the future.