
Red Hat reports security issue in Linux Kernel which was fixed 17 months prior - artistsvoid
https://www.openwall.com/lists/oss-security/2020/06/23/2
======
CrankyBear
Your 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
Moderators 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
"Red Hat finds security issue in Linux Kernel that had been fixed upstream for
17 months"

~~~
m4r71n
More 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.

------
8organicbits
Can 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?)

~~~
jcrawfordor
Red 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.

~~~
ebiggers
> 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.

This isn't unusual. This is actually the usual case.

The unusual thing here is actually that someone downstream noticed they were
missing a fix (probably because its LTP regression test was failing, which is
also unusual because most kernel fixes don't have an LTP regression test).

More commonly, no one notices and these bugs never get fixed in downstream
kernels that aren't staying up to-date with LTS; and there is never a CVE, an
oss-security post, a Hacker News thread, etc. But these bugs are still there.

~~~
bonzini
> More commonly, no one notices and these bugs never get fixed in downstream
> kernels that aren't staying up to-date with LTS

Actually a lot of RHEL subsystems are updated wholesale by including all
upstream patches (not just those that go into LTS kernels), and this way all
such fixes are automatically included.

------
baggy_trough
Why don't Red Hat et al use the LTS kernels?

~~~
Conan_Kudo
Note 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
Seems like even Arch maintains it's own kernel. Not uncommon for distros to do
it at all.

~~~
artistsvoid
Wrong, 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&i...](https://git.archlinux.org/linux.git/commit/?h=v5.7.5-arch1&id=35f8fcadda6fd6d6eb582a7750ee307b2b822686)

~~~
bluedays
They 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.

~~~
phh
"maintaining your own kernel" in this context means that you're bringing
bugfixes (including security) independently from the mainline Linux kernel,
which would usually involve cherry-picking commits from the mainline.

Archlinux doesn't do that, and straight merges Linux mainline.

------
mikevm
I 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 :(.

~~~
awill
It can be frustrating, but it's almost always worth it in a serious production
environment.

I have my own anecdote: I have serveral home servers running CentOS 7 (set up
nearly 6 years ago). I update all the time and I've had zero issues. Literally
nothing has ever broken. My previous servers ran CentOS 6, and were equally
reliable.

My desktop runs Arch Linux, and gets ever kernel dot release. I've had an
unbootable system at least 5 times over the last 5 years, requiring me to boot
from a flash drive to downgrade a package, or edit a grub config. As you can
imagine, it's bitten me at the worst possible time (when I really don't have
time to troubleshoot).

I know some people advocate for Arch on the server, but to me that seems
crazy. Nothing against Arch. It's great for a desktop, and I knowingly trade
off some reliability/stability for the latest stuff. I wouldn't make that
trade on a server that hosted important stuff.

~~~
gbrown
Fedora seems like a sensible middle ground.

------
despera
While 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
And 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
I 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
Hell 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.

~~~
despera
How is no marking better than some marking?

If there is a commit that refers to a "memory leak" why shouldn't be, at least
superfluously, checked, identified and have distros informed? (e.g
2ca068be09bf8e285036603823696140026dcbe7)

If the crypto fix was assigned early as a vulnerability would have stayed
unpatched for that long?

~~~
eqvinox
> How is no marking better than some marking?

With no marking it is clear what it means: commits have not been audited to
identify security-relevant ones.

With partial, incomplete marking, unmarked commits can be one of two things:
commits that have not been looked at, and commits that have been looked at and
are believed to contain no security relevant changes.

The majority of commits will be in the "not looked at" category. And there's
enough people around to have a significant subset of them be lazy, ignorant,
unskilled or stupid and take that as "contains no security relevant changes."

P.S.: also, patches are already marked. By being included in the LTS series.
Because that means they were important enough to get a backport — though not
necessarily due to security impact.

~~~
despera
I do agree with the premises, i don't agree with your conclusion.

Yes only a part of patches would be marked as such. That, major or minor, part
would simply mean that people won't have to reinvent the particular wheel, as
happened in this case. People won't be missing critical _discovered_ changes,
the vulnerability would be discussed, recognized in its totality (PoC,
documentation etc) and proper patches will be offered. There have been cases
where LTS backports were old revisions of bad patches.

I think that baking LTS kernels is unnecessarily closer to an artistic
approach of doing things.

