9 ms·
Red Hat reports security issue in Linux Kernel which was fixed 17 months prior
- deleted 6y ago[deleted]
- baggy_trough 6y agoWhy don't Red Hat et al use the LTS kernels?
- pjmlp 6y agoProbably drivers.
- bubblethink 6y agoWhat about them ? I don't think the OP means using the upstream kernel directly, just why they don't use the same version as the LTS version.
- tssva 6y agoReasons I can think of include: Not wanting to be tied to a kernel LTS release cycle you don't control. The need to backport features and hardware enablement to the LTS kernel significantly offsets some of the benefits of using a LTS kernel. The length of support for LTS kernels is significantly shorter than Redhat's length of support which means they would end up supporting it on their own for a significant timeframe anyways.
- gregkh 6y agoThey feel like they know better and do not want all of the fixes that the LTS kernels provide for some crazy reason. I suggest you contact them if you rely on a RHEL kernel to ask them why they do this, it's always seemed crazy. Note, I'm the person who does the LTS kernel releases, maybe they just don't like me :)
- rwmj 6y agoI'm certain that Red Hat and our kernel developers have no animosity towards you, in fact it's completely the opposite. You're well known in the community not just for this but for maintaining and writing countless drivers and loads of other great work in the kernel. Fedora does use the LTS kernels.
- stonogo 6y agoIt could also be motivated by the fact that it's not entirely wise to base an entire multibillion dollar business around whatever text a non-employee happens to push to a repo you don't control.
- gregkh 6y agoAndroid doesn't seem to mind, they require the LTS updates to be taken for their devices (well, "require" is a strong word, they are pushing harder now than they were in the past, "required" will be happening in the future, hopefully...) As the number of systems running RHEL is really just a rounding error compared to the number of Android systems out there, maybe it doesn't really matter :)
- azinman2 6y agoI would guess that RHEL has more stringent requirements than your average me-too Android manufacturer.
- radiator 6y agoBut do the devices running Android generally operate with the same requirements as the servers running RHEL?
- nordsieck 6y ago> But do the devices running Android generally operate with the same requirements as the servers running RHEL? I guess it depends on the device and the business. How many days of downtime on Amazon.com is the cost of bricking 1M phones? Or 100M?
- gulikoza 6y agoRed Hat sometimes also backports new features, not just security fixes. In the first years of RHEL life cycle new features and certain upgrades are usually added to the point releases. This is actually nicer than being locked into same feature kernel for 10 years...for those that can't afford the changes, you have the Extended Support for each point release which then gets only the security fixes.
- Conan_Kudo 6y agoNote that Red Hat, SUSE, and Canonical all don't use them. They maintain their own kernel trees with their modifications. These kernel teams have different priorities: * stable ABI within a timespan (RH, SUSE) * feature backports based on customer demand (all three) * out of tree goop (Canonical) I've also heard from others (though notably, not folks specifically at these companies) that longterm kernels are iffier than regular stable kernels because people come out of the woodwork to push weird stuff for longterm kernels, which destabilizes things more than with regular stable kernels.
- bluedays 6y agoSeems like even Arch maintains it's own kernel. Not uncommon for distros to do it at all.
- artistsvoid 6y agoWrong, or at the least misleading. What do you mean by 'maintain' here? Because Arch is trying to stay on the bleeding edge side of things in a reasonable manner and is rolling release, they almost stay 1:1 with upstream, "maintains its own kernel" makes it sound like they would do some heavy patching and do active maintenance with certain kernel versions, et cetera. You can have a look yourself if you want to https://git.archlinux.org/linux.git/commit/?h=v5.7.5-arch1&id=35f8fcadda6fd6d6eb582a7750ee307b2b822686 https://git.archlinux.org/linux.git/commit/?h=v5.7.5-arch1&i...
- bluedays 6y agoThey have their own kernel as can be seen here: https://i.imgur.com/jP6Pdvq.png https://i.imgur.com/jP6Pdvq.png Also if you look at the diffstat you can see that there were a number of changes here: https://i.imgur.com/J2em78v.png https://i.imgur.com/J2em78v.png It may be align with the majority of the kernel, but these patches exist in every version of the kernel that is released by Arch. What else could that be called aside from maintaining your own kernel? These changes are extremely small within scope which is the nature of Arch, but they still exist. A more hands-on distro will see many more changes than Arch, naturally. However, as evidenced from the above you can see that Arch does have it's own kernel and I cited Arch as an example because it strives so hard to maintain 1:1 with upstream. Btw, I use Arch.
- drewg123 6y agoRHEL maintains a KABI to support binary device drivers. Given how frequently the linux kernel changes internal APIs, this would be much harder or even impossible if they changed kernel versions regularly. Instead, they take features and bugfixes from upstream and merge them back into their kernel version, auditing them for changes that would not be binary compatible.
- heavyset_go 6y agoUbuntu does the same thing. I'm only pointing it out because if you can't find a reason RH does it, you might be able to find the reason Canonical does it, though.
- CrankyBear 6y agoYour headline's misleading. Red Hat knows it's long been fixed in the LTS kernels, but it still needs patching in the RHEL kernels. Generally speaking, current LTS kernels are not used in older Linux distros.
- artistsvoid 6y agoModerators can of course change the title, I don't think it's misleading and I was not trying to be. I guess 'reports' could be changed into 'finds' and it could be mentioned that it was found 'in its Linux kernel', not sure when the character limit would hit. 'current LTS kernels are not used in older Linux distros' - not sure what your point is with this. They absolutely could have used / can use LTS kernels if they wanted to or they could merge LTS-kernel changes which they apparently don't.
- infogulch 6y ago"Red Hat finds security issue in Linux Kernel that had been fixed upstream for 17 months"
- m4r71n 6y agoMore like "Red Hat assigned a CVE to a security issue reported 17 months ago": https://bugzilla.redhat.com/show_bug.cgi?id=1708775 https://bugzilla.redhat.com/show_bug.cgi?id=1708775 I don't see what the big news here is, it's merely identifying a vulnerability with a proper CVE ID, end of story. The issue itself does not even have a serious security impact so it will likely never be fixed in RHEL.
- kasabali 6y ago> Generally speaking, current LTS kernels are not used in older Linux distros Debian always uses longterm branches. Sometimes Ubuntu, too.
- mikevm 6y agoI really hate the fact that RHEL updates kernels so slowly. This becomes very painful when your product cannot take advantage of some advanced kernel features just because you have customers running RHEL :(.
- bluedays 6y agoIs there anyway you can use a different kernel? The kernel is really easily replaceable in other distros. I don't know much about RHEL.
- pnutjam 6y agoNo, you can't do that in RHEL. It would invalidate support.
- sam_lowry_ 6y agoO'rly?
- bluedays 6y agoSeems sad that the modularity of Linux is not allowed due to issues with support. That, in my opinion, is the best part of Linux - which is finding solutions to problems that exists outside of the scope of what is designed by the vendors.
- azinman2 6y agoA big part of RHEL IS their kernel. They spend a lot of time to optimize/stabilize their releases. Why would they support any other kernel?
- yjftsjthsd-h 6y agoIt's a tradeoff. There's nothing to stop you from taking a RHEL system and installing the very latest kernel, and there's a good chance that the resulting system would work fine. However, RH the company only supports their own versions, which seems reasonable. Also, and not unrelated, I believe RHEL kernels hold a stable ABI to the point that you can use vendor-provided (out-of-tree) drivers and not have them break on every release, which is something that normal kernels intentionally don't support. So you can use RHEL like any other Linux system, but you lose some of the advantages that made RHEL useful in the first place.
- 8organicbits 6y agoCan someone in the kernel dev space give a longer explanation for this? This looks to me like Red Hat assigning a CVE to something patched a long time ago. Is this just record keeping to label security issues with CVEs or has Red Hat left this unpatched for 17 months? (Or something else?)
- parliament32 6y agoSounds like the latter. They "found" it and requested a CVE, but it was already fixed -- they just hadn't merged that change because they didn't notice it was security-related.
- jcrawfordor 6y agoRed Hat's security program includes disclosing and tracking security vulnerabilities found in its products. As part of doing this, they obtain CVEs for any vulnerabilities which did not previously have them. CVE IDs are required by US gov't and many corporate security programs, as the broader point of the CVE system is not only to provide standardized identification of vulnerabilities but also assign certain metadata (such as a severity category) which is used by many vulnerability management programs. Basically, having a CVE ID assigned makes it much easier for the vulnerability to be included in automated tools. Because Red Hat builds on open-source software and generally lags well behind the cutting edge, usually by the time RH identifies a problem in something like the Linux kernel it has already been found, reported, and assigned a CVE ID by someone else (unless it's discovered by RH's own kernel developers, in which case they would of course be working on a fix at the same time that they start the vulnerability process). In this somewhat unusual case, the problem was found and corrected in the Linux kernel through a typical bug-fix process and not handled as a security vulnerability, so no CVE was assigned. When RH discovered the problem they made a determination that it should be handled as a security vulnerability, and so that triggered their normal process of disclosing and requesting that a CVE ID be assigned - in this case, even though the problem had already been fixed. It's not especially significant to this that RH had not backported the fix for this particular problem, as RH would generally go through a vulnerability process anyway because of the simple fact that some RH customers have not updated their systems, and so the vulnerability needs to be reported to them. Overall the whole thing is not particularly interesting, really just a bit of security bookkeeping, except that it does expose that RH does not necessarily integrate LTS Linux releases, which means that they will sometimes not obtain security fixes included in such releases. Most of the time such security fixes would be treated as vulnerabilities by the organization that made them and the broader Linux community which would trigger RH's internal vulnerability management process leading to the fix being rolled out to RH products. However, many Linux bugs with potential security implications are not judged by the people finding and fixing them to be severe enough to merit a security vulnerability process... for instance, virtually every memory handling problem could be viewed as a vulnerability but requesting a CVE ID etc. is wasted effort if the problem is unlikely to be exploitable. The "unlikely" can be hard to tell. Ultimately this is sometimes a judgment call and different organizations will disagree, sometimes leading to situations like this where a downstream user chooses to treat it as a vulnerability after the fact.
- despera 6y agoWhile RedHat's backporting might not be great, i believe that upstream would do good if they would change their mind about having or not a well defined vulnerability identification and notification system. It's understandable that almost every piece of kernel code could potentially be a bad actor thus it would be tough to identify if every fix has security implications or not. Still there must be a middle ground around common exploitation methods.
- gregkh 6y agoAnd what would that "middle ground" look like? With the current rate of change that the kernel community develops at, including the patches backported to the stable/longterm kernels, it's impossible to try to evaluate each and every patch for "is this something that could be exploited or not?" Companies have tried, it was fun watching them, but they quickly gave up and declared it impossible and much safer to just take all stable patch updates instead. I've also talked to MITRE about just applying for a CVE for ever stable kernel patch (20+ a day), and while they appreciated me not doing that, they agreed that the current model of CVEs just does not work at all for the Linux kernel and that what we are doing is fine. See my Kernel Recipes talk last year for details about all of that if you are curious.
- despera 6y agoI understand that completely and i already know your thoughts on that and in some extend i do agree. Still, i think we do have in hand a very characteristic issue that even without knowing the details, simply by searching commit messages for "crypto" "key" "buffer" etc it should alert somebody to give it a second and third look.
- eqvinox 6y agoHell no. You can't just "guess by words." The only thing (far!) worse than no impact marking is incomplete impact marking. That's just giving people a way to cop out, and they WILL use it.