Loop with Unreachable Exit Condition ('Infinite Loop') Affecting kernel-64k-debug-devel-matched package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS10-KERNEL64KDEBUGDEVELMATCHED-16705431
- published16 May 2026
- disclosed13 May 2026
Introduced: 13 May 2026
NewCVE-2026-43486 (opens in a new tab)How to fix?
There is no fixed version for Centos:10 kernel-64k-debug-devel-matched.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-64k-debug-devel-matched package and not the kernel-64k-debug-devel-matched package as distributed by Centos.
See How to fix? for Centos:10 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
arm64: contpte: fix set_access_flags() no-op check for SMMU/ATS faults
contpte_ptep_set_access_flags() compared the gathered ptep_get() value against the requested entry to detect no-ops. ptep_get() ORs AF/dirty from all sub-PTEs in the CONT block, so a dirty sibling can make the target appear already-dirty. When the gathered value matches entry, the function returns 0 even though the target sub-PTE still has PTE_RDONLY set in hardware.
For a CPU with FEAT_HAFDBS this gathered view is fine, since hardware may set AF/dirty on any sub-PTE and CPU TLB behavior is effectively gathered across the CONT range. But page-table walkers that evaluate each descriptor individually (e.g. a CPU without DBM support, or an SMMU without HTTU, or with HA/HD disabled in CD.TCR) can keep faulting on the unchanged target sub-PTE, causing an infinite fault loop.
Gathering can therefore cause false no-ops when only a sibling has been updated:
- write faults: target still has PTE_RDONLY (needs PTE_RDONLY cleared)
- read faults: target still lacks PTE_AF
Fix by checking each sub-PTE against the requested AF/dirty/write state (the same bits consumed by __ptep_set_access_flags()), using raw per-PTE values rather than the gathered ptep_get() view, before returning no-op. Keep using the raw target PTE for the write-bit unfold decision.
Per Arm ARM (DDI 0487) D8.7.1 ("The Contiguous bit"), any sub-PTE in a CONT range may become the effective cached translation and software must maintain consistent attributes across the range.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2477140
- https://access.redhat.com/security/cve/CVE-2026-43486
- https://git.kernel.org/stable/c/05d239f2c95e66e27e7fb4e99ee07eb56e3e34b0
- https://git.kernel.org/stable/c/09d620555e59768776090073a2c59d2bc8506eb3
- https://git.kernel.org/stable/c/6f92a7a8b48a523f910ef25dd83808710724f59b
- https://git.kernel.org/stable/c/97c5550b763171dbef61e6239cab372b9f9cd4a2