Loop with Unreachable Exit Condition ('Infinite Loop') Affecting kernel-zfcpdump-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-KERNELZFCPDUMPDEVELMATCHED-16953963
- published28 May 2026
- disclosed27 May 2026
Introduced: 27 May 2026
NewCVE-2026-45895 (opens in a new tab)How to fix?
There is no fixed version for Centos:10 kernel-zfcpdump-devel-matched.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump-devel-matched package and not the kernel-zfcpdump-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:
quota: fix livelock between quotactl and freeze_super
When a filesystem is frozen, quotactl_block() enters a retry loop waiting for the filesystem to thaw. It acquires s_umount, checks the freeze state, drops s_umount and uses sb_start_write() - sb_end_write() pair to wait for the unfreeze.
However, this retry loop can trigger a livelock issue, specifically on kernels with preemption disabled.
The mechanism is as follows:
- freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write().
- sb_wait_write() calls percpu_down_write(), which initiates synchronize_rcu().
- Simultaneously, quotactl_block() spins in its retry loop, immediately executing the sb_start_write() - sb_end_write() pair.
- Because the kernel is non-preemptible and the loop contains no scheduling points, quotactl_block() never yields the CPU. This prevents that CPU from reaching an RCU quiescent state.
- synchronize_rcu() in the freezer thread waits indefinitely for the quotactl_block() CPU to report a quiescent state.
- quotactl_block() spins indefinitely waiting for the freezer to advance, which it cannot do as it is blocked on the RCU sync.
This results in a hang of the freezer process and 100% CPU usage by the quota process.
While this can occur intermittently on multi-core systems, it is reliably reproducing on a node with the following script, running both the freezer and the quota toggle on the same CPU:
mkfs.ext4 -O quota /dev/sda 2g && mkdir a_mount
mount /dev/sda -o quota,usrquota,grpquota a_mount
taskset -c 3 bash -c "while true; do xfs_freeze -f a_mount; \
xfs_freeze -u a_mount; done" &
taskset -c 3 bash -c "while true; do quotaon a_mount; \
quotaoff a_mount; done" &
Adding cond_resched() to the retry loop fixes the issue. It acts as an RCU quiescent state, allowing synchronize_rcu() in percpu_down_write() to complete.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2482169
- https://access.redhat.com/security/cve/CVE-2026-45895
- https://git.kernel.org/stable/c/02bb1500f1479750e6557c8044f6a2d7e9d30c12
- https://git.kernel.org/stable/c/37ccd48cf35f3c8b9f2ea961a7b486b91eb71a82
- https://git.kernel.org/stable/c/414259caf81a397563fc9baca9c0ef856c4a97cf
- https://git.kernel.org/stable/c/53b2314b26b6640a3657cc924de63a1a8f26ac4d
- https://git.kernel.org/stable/c/77449e453dfc006ad738dec55374c4cbc056fd39