The Linux kernel decides what your AMD processor is by reading a family and a model number, then looking them up in a table. Get the table wrong and everything gated on it gets subtly wrong too: errata workarounds, power management behaviour, performance counters. A patch merged for Linux 7.2-rc6 fixes exactly that kind of mistake. An earlier change had given the whole 0xd0 to 0xef model range in Family 1Ah to Zen 6, when 0xd0 through 0xd7 is reserved for Zen 5. The correction splits the range properly, and it lands before 7.2 becomes a stable kernel that distributions carry for years.
The short answer
A patch merged ahead of Linux 7.2-rc6 corrects AMD CPU model ranges. A change from May thirtieth had extended Zen 6 to cover models 0xc0 through 0xef in Family 1Ah, but 0xd0 to 0xd7 is reserved for Zen 5. The fix, commit 52075128273ace53e6254e37899a47d40d4baf45, hands that block back and leaves Zen 6 with 0x50 to 0x5f, 0x80 to 0xaf, 0xc0 to 0xcf and 0xd8 to 0xef. No shipping processor was affected, since these ranges are reservations for parts that are not out yet. The same batch of x86 fixes also corrected a memcmp() problem affecting Xen guests.
There is a particular kind of kernel bug that never shows up in a bug report, because the hardware it would affect does not exist yet. It sits in a table, correct looking, waiting for silicon to arrive and prove it wrong. The AMD model range mix up fixed for Linux 7.2-rc6 is one of those, and the interesting part is not the bug. It is what the kernel does with those numbers.
Eight model numbers, given back
Zen 5 and Zen 6 share Family 1Ah, 26 in decimal, and are told apart only by model number. On May thirtieth, 2026, a patch from Pratik Vishwakarma at AMD widened the Zen 6 detection range, taking the final block from 0xc0 through 0xcf out to 0xef in one step. That kind of expansion is routine, since AMD reserves model space in advance so that new Ryzen and EPYC parts are recognised by kernels that predate them.
The expansion took too much. Models 0xd0 through 0xd7 belong to Zen 5, and the corrective patch merged for 7.2-rc6 splits the range accordingly. Zen 6 keeps 0xc0 to 0xcf and 0xd8 to 0xef, on top of the 0x50 to 0x5f and 0x80 to 0xaf ranges it already had. Zen 5 gets its eight models back. The commit is 52075128273ace53e6254e37899a47d40d4baf45.
Nobody's desktop was affected, and it is worth saying plainly rather than dressing this up as a near miss. These are reservations. What makes the timing matter is that Linux 7.2 is nearly out, and a stable kernel is not a thing you patch once. It is a thing that ships in enterprise distributions and gets carried for years, so a wrong entry has a long tail of backports, vendor kernels and confused bug reports behind it.
Why a table lookup deserves this much care
The reason the kernel cares which generation a chip belongs to is that family and model matching gates real behaviour.
The most consequential use is errata. Processor errata are per model, and the workarounds for them are applied by matching family, model and stepping. A chip filed under the wrong generation can match a workaround written for different silicon, or miss one written for its own. That is the case with actual correctness at stake, and it is the reason these tables get reviewed carefully rather than rubber stamped.
The rest is performance and observability. The amd_pstate driver behaves differently across generations, and generational gating has been part of several recent scheduling and boost changes. Performance monitoring maps events per microarchitecture, so a wrong generation means counters that either do not exist or mean something else. EDAC binds memory controller support by model. Thermal and power reporting paths make similar checks.
None of that typically produces a crash. It produces a machine that boots, runs, and is quietly a few percent off, or reports numbers that do not mean what the dashboard label says. Those are the expensive failures, because nobody opens a ticket for them.
Checking your own machines
The values are easy to read and worth reading on anything recently deployed. lscpu prints CPU family, Model and Model name together, and the same numbers appear in /proc/cpuinfo as cpu family and model. The catch that trips people is bases: family 26 in lscpu is the 1Ah you see in patches and errata documents, and the model is printed in decimal while AMD and kernel commits talk in hex. printf '%x\n' 208 returns d0 and settles it.
The signal to watch for on new hardware is not a wrong number, it is a vague one. A generic Model name string, or a family and model your kernel clearly has no table entry for, tells you the running kernel is older than the silicon. Everything gated on generation is then running on defaults rather than on knowledge of your part, which is usually fine and occasionally is not.
For anyone tracking 7.2, this fix arrived with a batch of x86 corrections that also included a memcmp() fix affecting Xen virtual machines, and rc6 was due within about twelve hours of the report on August second. On the normal cadence that puts stable 7.2 a few weeks out.
Sources and further reading
- Phoronix: Linux 7.2-rc6 fixes some AMD Zen 5 CPUs being mistakenly identified as Zen 6
- Phoronix: AMD expands the range of Zen 6 CPUs detected by the Linux kernel
- Wccftech: AMD expands Zen 6 family support in Linux
- Kernel documentation: the amd_pstate driver
- lscpu manual page
Frequently asked questions
Did this bug break anything on machines people actually own?
Almost certainly not, and that is the honest framing. The ranges involved are reservations for silicon that has not shipped, which is why the mistake survived from late May to early August without anyone tripping over it. AMD publishes model ranges ahead of launch so the kernel recognises new parts on day one rather than six months later, and that pre provisioning is exactly where an off by a few nibbles error is cheapest to make and cheapest to fix. The reason it matters is timing rather than blast radius: Linux 7.2 is close to release, distributions will carry it for a long time, and a wrong model table baked into a long lived kernel is a support problem that outlives the patch that caused it.
What are the corrected ranges?
Both architectures live in Family 1Ah, which is 26 in decimal. After the fix, Zen 5 owns models 0xd0 to 0xd7 in the contested block, and Zen 6 owns 0xc0 to 0xcf plus 0xd8 to 0xef, alongside its existing 0x50 to 0x5f and 0x80 to 0xaf ranges. The change reverses part of a patch from May thirtieth, 2026, submitted by Pratik Vishwakarma of AMD, which had extended the Zen 6 block from 0xc0 through 0xcf out to 0xef in one move. The corrective commit is 52075128273ace53e6254e37899a47d40d4baf45.
What actually depends on the kernel knowing which Zen generation a chip is?
More than most people expect. The x86 code uses family and model matching to decide which errata workarounds to apply, which is the part with real correctness consequences. Beyond that, the amd_pstate driver keys behaviour off generation, performance monitoring code maps events differently per microarchitecture, EDAC binds memory controller support by model, and thermal and power reporting paths make similar checks. A mislabelled generation does not usually produce a crash. It produces a machine that runs, and runs slightly wrong, in ways that are painful to attribute later.
How do I check what my kernel thinks my CPU is?
Run lscpu and read the CPU family, Model and Model name fields together. Family 26 is 1Ah in hexadecimal, and the model number is printed in decimal, so convert it before comparing against ranges published in hex: printf '%x\n' 208 gives d0. The same values are in /proc/cpuinfo as cpu family and model. If you want the raw view, the cpuid utility from most distribution repositories dumps the leaves directly. The useful habit on any new platform is to check that the model name string is populated and specific, since a generic string is often the first sign that the running kernel predates the silicon.
Was this the only x86 fix in that batch?
No. The same set of x86 fixes heading into 7.2-rc6 also carried a correction to the memcmp() implementation that affected Xen virtual machines. Late release candidates are usually made of exactly this material: small, contained corrections to things that would be expensive to discover after release. Linux 7.2-rc6 was due out within roughly twelve hours of the fix being reported on August second, which puts the stable 7.2 release a few weeks away on the usual cadence.