Linux Kernel up to 6.18.15/6.19.5 move_dirty_folio_in_page_array infinite loop

Summaryinfo

A vulnerability was found in Linux Kernel up to 6.18.15/6.19.5. It has been rated as critical. This impacts the function move_dirty_folio_in_page_array. The manipulation leads to infinite loop. This vulnerability is listed as CVE-2026-43188. There is no available exploit. Upgrading the affected component is advised.

Detailsinfo

A vulnerability was found in Linux Kernel up to 6.18.15/6.19.5. It has been rated as critical. This issue affects the function move_dirty_folio_in_page_array. The manipulation with an unknown input leads to a infinite loop vulnerability. Using CWE to declare the problem leads to CWE-835. The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop. Impacted is availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: ceph: do not propagate page array emplacement errors as batch errors When fscrypt is enabled, move_dirty_folio_in_page_array() may fail because it needs to allocate bounce buffers to store the encrypted versions of each folio. Each folio beyond the first allocates its bounce buffer with GFP_NOWAIT. Failures are common (and expected) under this allocation mode; they should flush (not abort) the batch. However, ceph_process_folio_batch() uses the same `rc` variable for its own return code and for capturing the return codes of its routine calls; failing to reset `rc` back to 0 results in the error being propagated out to the main writeback loop, which cannot actually tolerate any errors here: once `ceph_wbc.pages` is allocated, it must be passed to ceph_submit_write() to be freed. If it survives until the next iteration (e.g. due to the goto being followed), ceph_allocate_page_array()'s BUG_ON() will oops the worker. Note that this failure mode is currently masked due to another bug (addressed next in this series) that prevents multiple encrypted folios from being selected for the same write. For now, just reset `rc` when redirtying the folio to prevent errors in move_dirty_folio_in_page_array() from propagating. Note that move_dirty_folio_in_page_array() is careful never to return errors on the first folio, so there is no need to check for that. After this change, ceph_process_folio_batch() no longer returns errors; its only remaining failure indicator is `locked_pages == 0`, which the caller already handles correctly.

It is possible to read the advisory at git.kernel.org. The identification of this vulnerability is CVE-2026-43188 since 05/01/2026. Technical details of the vulnerability are known, but there is no available exploit.

The vulnerability scanner Nessus provides a plugin with the ID 313158 (Linux Distros Unpatched Vulnerability : CVE-2026-43188), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.18.16 or 6.19.6 eliminates this vulnerability. Applying the patch 746840c87d76b614b14d9337c466ff022fc49823/4c0d84c788d89c167abf0bf84fd37890c4c84f08/707104682e3c163f7c14cdd6b07a3e95fb374759 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the vulnerability database at Tenable (313158). Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.18.0
• 6.18.1
• 6.18.2
• 6.18.3
• 6.18.4
• 6.18.5
• 6.18.6
• 6.18.7
• 6.18.8
• 6.18.9
• 6.18.10
• 6.18.11
• 6.18.12
• 6.18.13
• 6.18.14
• 6.18.15
• 6.19.0
• 6.19.1
• 6.19.2
• 6.19.3
• 6.19.4
• 6.19.5

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion