Bug 2239097 (CVE-2023-23583)

Created microcode_ctl tracking bugs for this issue:

Affects: fedora-all [bug 2249669]

For information about microcode availability, check the Red Hat article https://access.redhat.com/articles/7044453

https://access.redhat.com/security/cve/cve-2023-23583 states that the microcode_ctl packages by red hat are not affected, but they are affected until the microcode gets from microcode-20230808 to microcode-20231114, right?

In reply to comment #5:
> https://access.redhat.com/security/cve/cve-2023-23583 states that the
> microcode_ctl packages by red hat are not affected, but they are affected
> until the microcode gets from microcode-20230808 to microcode-20231114,
> right?

Right, thanks for spotting this. We are updating the CVE page to list microcode_ctl packages as "Affected".

In reply to comment #5:
> https://access.redhat.com/security/cve/cve-2023-23583 states that the
> microcode_ctl packages by red hat are not affected, but they are affected
> until the microcode gets from microcode-20230808 to microcode-20231114,
> right?

Hi Klaas,
We have reverted back to the original state - which states that RHEL is *not affected* by this CVE.
Correctly speaking, the Intel processors are the affected part, and there are no kernel countermeasures or defects for this issue.

That said, the RHEL products and components are *not affected*.
The microcode_ctl package is a Red Hat courtesy to our customers to get updates for the Intel microcode that addresses this vulnerability.

We have a KB article which is also visible at the CVE page - https://access.redhat.com/articles/7044453 where you can track the microcode availability for the eligible RHEL versions.

(In reply to Rodrigo A B Freire from comment #9)
> In reply to comment #5:
> > https://access.redhat.com/security/cve/cve-2023-23583 states that the
> > microcode_ctl packages by red hat are not affected, but they are affected
> > until the microcode gets from microcode-20230808 to microcode-20231114,
> > right?
> 
> Hi Klaas,
> We have reverted back to the original state - which states that RHEL is *not
> affected* by this CVE.
> Correctly speaking, the Intel processors are the affected part, and there
> are no kernel countermeasures or defects for this issue.
> 
> That said, the RHEL products and components are *not affected*.
> The microcode_ctl package is a Red Hat courtesy to our customers to get
> updates for the Intel microcode that addresses this vulnerability.
> 
> We have a KB article which is also visible at the CVE page -
> https://access.redhat.com/articles/7044453 where you can track the microcode
> availability for the eligible RHEL versions.

I'll be honest, as a customer I do not understand that rationality. You have a package that is created by Red Hat, that comes from Red Hat repositories, is part of RHEL, that contains affected microcode instead of fixed microcode. Stating that this is "Not affected" is objectively wrong...

(In reply to Klaas Demter from comment #10)
> (In reply to Rodrigo A B Freire from comment #9)
> > In reply to comment #5:
> > > https://access.redhat.com/security/cve/cve-2023-23583 states that the
> > > microcode_ctl packages by red hat are not affected, but they are affected
> > > until the microcode gets from microcode-20230808 to microcode-20231114,
> > > right?
> > 
> > Hi Klaas,
> > We have reverted back to the original state - which states that RHEL is *not
> > affected* by this CVE.
> [SNIP]
> 
> I'll be honest, as a customer I do not understand that rationality. You have
> a package that is created by Red Hat, that comes from Red Hat repositories,
> is part of RHEL, that contains affected microcode instead of fixed
> microcode. Stating that this is "Not affected" is objectively wrong...

I fully agree with Klass about the confusion this will cause customers.  I was very confused when I first read the article the other day and saw "Not Affected".

I understand we're trying to say that nothing in RHEL is affected, but we need to find better words to say it.

Instead of "Not affected", would we state: "Only microde is affected"?

Joe

> I understand we're trying to say that nothing in RHEL is affected, but we need to find better words to say it.

but it is in RHEL, it's even something Red Hat can 'fix', I mean I would understand if Red Hat said "we can't fix it there is no new microcode", but there is new microcode, Red Hat just needs to ship it in it's package.

> Instead of "Not affected", would we state: "Only microde is affected"?

Would Red Hat also state "only binary blobs affected" if something is wrong in linux-firmware? :) https://access.redhat.com/security/cve/CVE-2023-20569 https://access.redhat.com/security/cve/CVE-2022-27635

Also if you finally upgrade microcode_ctl will you say "this does not fix CVE-2023-23583 because microcode_ctl was not affected" :)

I guess you see where I am heading with my arguments :)

There is a new microcode_ctl release, and well changelog states: "Update Intel CPU microcode to microcode-20231009 release, addresses CVE-2023-23583 (RHEL-3684)" ... :) I am guessing because you did not properly link those issues it doesn't show up as an errata on https://access.redhat.com/security/cve/cve-2023-23583

RHEL is not affected.

The affected product is the Intel silicon.

As a courtesy, Red Hat ships an Intel microcode update that mitigates the silicon problem.

(In reply to Rodrigo A B Freire from comment #14)
> RHEL is not affected.
> 
> The affected product is the Intel silicon.
> 
> As a courtesy, Red Hat ships an Intel microcode update that mitigates the
> silicon problem.

By the same (flawed) logic https://access.redhat.com/security/cve/CVE-2023-20569 should not list your linux-firmware packages as affected.. it's a problem in the amd microcode..

I don't understand the reasoning here, feels very weird. One would think RedHat wants to ship the new Intel microcode in microcode_ctl as done for other microcode-related security issues, like was done for [1].

[1] https://gitlab.com/redhat/centos-stream/rpms/microcode_ctl/-/commit/8092411193d09c3cf443c8db6de66b4b79136965