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?)
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.
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.
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.