A /proc/PID/mem vulnerability

The black hats already have an easy source of security bugs: look at the "stable" releases and see what the diff is from last time. The majority of those are going to be security fixes, because if they weren't they would wait until the next quarterly release.

When Linux first grew "1.2.3.x" level releases, they would stop doing them as soon as a new kernel came out, and there was a gap between the last stable and the new kernel. I asked for one more release worth of overlap, so people stuck on old kernels could see what the fixes in need of backporting were without losing some in each gap between the last dot-release in the old kernel and the new quarterly kernel release. Greg agreed and started doing that.

(Since then various people have tried to do long term support for Random Kernels Your Vendor Did Not Provide, which is utterly useless to anybody using a board support package in the embedded space, and yet they keep hoping that If We Build It, They Will Stop Using The Thing The Other Guy Already Built. But the extra overlap closing the gap for the stable releases is still a good thing anyway.)

The danger with what Linus is doing is if he DOESN'T forward that commit to the stable guys. But presumably he did that.

Rob