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.