CVE-2024-57884: mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()

CVE-2024-57884: mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()

[Greg Kroah-Hartman]

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()

The task sometimes continues looping in throttle_direct_reclaim() because
allow_direct_reclaim(pgdat) keeps returning false.  

 #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac
 #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c
 #2 [ffff80002cb6f990] schedule at ffff800008abc50c
 #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550
 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68
 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660
 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98
 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8
 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974
 #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4

At this point, the pgdat contains the following two zones:

        NODE: 4  ZONE: 0  ADDR: ffff00817fffe540  NAME: "DMA32"
          SIZE: 20480  MIN/LOW/HIGH: 11/28/45
          VM_STAT:
                NR_FREE_PAGES: 359
        NR_ZONE_INACTIVE_ANON: 18813
          NR_ZONE_ACTIVE_ANON: 0
        NR_ZONE_INACTIVE_FILE: 50
          NR_ZONE_ACTIVE_FILE: 0
          NR_ZONE_UNEVICTABLE: 0
        NR_ZONE_WRITE_PENDING: 0
                     NR_MLOCK: 0
                    NR_BOUNCE: 0
                   NR_ZSPAGES: 0
            NR_FREE_CMA_PAGES: 0

        NODE: 4  ZONE: 1  ADDR: ffff00817fffec00  NAME: "Normal"
          SIZE: 8454144  PRESENT: 98304  MIN/LOW/HIGH: 68/166/264
          VM_STAT:
                NR_FREE_PAGES: 146
        NR_ZONE_INACTIVE_ANON: 94668
          NR_ZONE_ACTIVE_ANON: 3
        NR_ZONE_INACTIVE_FILE: 735
          NR_ZONE_ACTIVE_FILE: 78
          NR_ZONE_UNEVICTABLE: 0
        NR_ZONE_WRITE_PENDING: 0
                     NR_MLOCK: 0
                    NR_BOUNCE: 0
                   NR_ZSPAGES: 0
            NR_FREE_CMA_PAGES: 0

In allow_direct_reclaim(), while processing ZONE_DMA32, the sum of
inactive/active file-backed pages calculated in zone_reclaimable_pages()
based on the result of zone_page_state_snapshot() is zero.  

Additionally, since this system lacks swap, the calculation of inactive/
active anonymous pages is skipped.

        crash> p nr_swap_pages
        nr_swap_pages = $1937 = {
          counter = 0
        }

As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on to
the processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 having
free pages significantly exceeding the high watermark.

The problem is that the pgdat->kswapd_failures hasn't been incremented.

        crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures
        $1935 = 0x0

This is because the node deemed balanced.  The node balancing logic in
balance_pgdat() evaluates all zones collectively.  If one or more zones
(e.g., ZONE_DMA32) have enough free pages to meet their watermarks, the
entire node is deemed balanced.  This causes balance_pgdat() to exit early
before incrementing the kswapd_failures, as it considers the overall
memory state acceptable, even though some zones (like ZONE_NORMAL) remain
under significant pressure.


The patch ensures that zone_reclaimable_pages() includes free pages
(NR_FREE_PAGES) in its calculation when no other reclaimable pages are
available (e.g., file-backed or anonymous pages).  This change prevents
zones like ZONE_DMA32, which have sufficient free pages, from being
mistakenly deemed unreclaimable.  By doing so, the patch ensures proper
node balancing, avoids masking pressure on other zones like ZONE_NORMAL,
and prevents infinite loops in throttle_direct_reclaim() caused by
allow_direct_reclaim(pgdat) repeatedly returning false.


The kernel hangs due to a task stuck in throttle_direct_reclaim(), caused
by a node being incorrectly deemed balanced despite pressure in certain
zones, such as ZONE_NORMAL.  This issue arises from
zone_reclaimable_pages() returning 0 for zones without reclaimable file-
backed or anonymous pages, causing zones like ZONE_DMA32 with sufficient
free pages to be skipped.

The lack of swap or reclaimable pages results in ZONE_DMA32 being ignored
during reclaim, masking pressure in other zones.  Consequently,
pgdat->kswapd_failures remains 0 in balance_pgdat(), preventing fallback
mechanisms in allow_direct_reclaim() from being triggered, leading to an
infinite loop in throttle_direct_reclaim().

This patch modifies zone_reclaimable_pages() to account for free pages
(NR_FREE_PAGES) when no other reclaimable pages exist.  This ensures zones
with sufficient free pages are not skipped, enabling proper balancing and
reclaim behavior.

[akpm@linux-foundation.org: coding-style cleanups]

The Linux kernel CVE team has assigned CVE-2024-57884 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.8 with commit 5a1c84b404a7176b8b36e2a0041b6f0adb3151a3 and fixed in 5.4.289 with commit 66cd37660ec34ec444fe42f2277330ae4a36bb19
	Issue introduced in 4.8 with commit 5a1c84b404a7176b8b36e2a0041b6f0adb3151a3 and fixed in 5.10.233 with commit d675fefbaec3815b3ae0af1bebd97f27df3a05c8
	Issue introduced in 4.8 with commit 5a1c84b404a7176b8b36e2a0041b6f0adb3151a3 and fixed in 5.15.176 with commit 63eac98d6f0898229f515cb62fe4e4db2430e99c
	Issue introduced in 4.8 with commit 5a1c84b404a7176b8b36e2a0041b6f0adb3151a3 and fixed in 6.1.124 with commit bfb701192129803191c9cd6cdd1f82cd07f8de2c
	Issue introduced in 4.8 with commit 5a1c84b404a7176b8b36e2a0041b6f0adb3151a3 and fixed in 6.6.70 with commit 1ff2302e8aeac7f2eedb551d7a89617283b5c6b2
	Issue introduced in 4.8 with commit 5a1c84b404a7176b8b36e2a0041b6f0adb3151a3 and fixed in 6.12.9 with commit 58d0d02dbc67438fc80223fdd7bbc49cf0733284
	Issue introduced in 4.8 with commit 5a1c84b404a7176b8b36e2a0041b6f0adb3151a3 and fixed in 6.13-rc6 with commit 6aaced5abd32e2a57cd94fd64f824514d0361da8

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-57884
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	mm/vmscan.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/66cd37660ec34ec444fe42f2277330ae4a36bb19
	https://git.kernel.org/stable/c/d675fefbaec3815b3ae0af1bebd97f27df3a05c8
	https://git.kernel.org/stable/c/63eac98d6f0898229f515cb62fe4e4db2430e99c
	https://git.kernel.org/stable/c/bfb701192129803191c9cd6cdd1f82cd07f8de2c
	https://git.kernel.org/stable/c/1ff2302e8aeac7f2eedb551d7a89617283b5c6b2
	https://git.kernel.org/stable/c/58d0d02dbc67438fc80223fdd7bbc49cf0733284
	https://git.kernel.org/stable/c/6aaced5abd32e2a57cd94fd64f824514d0361da8

CVE-2024-57884 patch review feedback (https://lore.kernel.org/linux-cve-announce/2025011510-CVE-2024-57884-4cf8@gregkh/#R)

[liuqiqi]

		if (cpusets_enabled() &&
			(alloc_flags & ALLOC_CPUSET) &&
			!__cpuset_zone_allowed(zone, gfp_mask))
				continue;

		available = reclaimable = zone_reclaimable_pages(zone);
		available += zone_page_state_snapshot(zone, NR_FREE_PAGES);

		/*
		 * Would the allocation succeed if we reclaimed all
		 * reclaimable pages?
		 */
		wmark = __zone_watermark_ok(zone, order, min_wmark,
				ac->highest_zoneidx, alloc_flags, available);

compaction_zonelist_suitable() function has the same problem.
bool compaction_zonelist_suitable(struct alloc_context *ac, int order,
		int alloc_flags)
{
	struct zone *zone;
	struct zoneref *z;

	/*
	 * Make sure at least one zone would pass __compaction_suitable if we continue
	 * retrying the reclaim.
	 */
	for_each_zone_zonelist_nodemask(zone, z, ac->zonelist,
				ac->highest_zoneidx, ac->nodemask) {
		unsigned long available;

		/*
		 * Do not consider all the reclaimable memory because we do not
		 * want to trash just for a single high order allocation which
		 * is even not guaranteed to appear even if __compaction_suitable
		 * is happy about the watermark check.
		 */
		available = zone_reclaimable_pages(zone) / order;
		available += zone_page_state_snapshot(zone, NR_FREE_PAGES);
		if (__compaction_suitable(zone, order, min_wmark_pages(zone),
					  ac->highest_zoneidx, available))

If this is problematic, can it be modified as follows:
diff --git a/mm/vmscan.c b/mm/vmscan.c
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -6417,7 +6417,7 @@ static bool allow_direct_reclaim(pg_data_t *pgdat)
                return true;
 
        for_each_managed_zone_pgdat(zone, pgdat, i, ZONE_NORMAL) {
-               if (!zone_reclaimable_pages(zone))
+               if (!zone_reclaimable_pages(zone) || !(zone_page_state_snapshot(zone, NR_FREE_PAGES)))
                        continue;

Signed-off-by: liuqiqi <liuqiqi@kylinos.cn>

CVE-2024-57884 patch review feedback (https://lore.kernel.org/linux-cve-announce/2025011510-CVE-2024-57884-4cf8@gregkh/#R)

[liuqiqi]

CVE-2024-57884  patch fixes  mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim() modify as follows
@@ -342,7 +342,14 @@ unsigned long zone_reclaimable_pages(struct zone *zone)
 	if (get_nr_swap_pages() > 0)
 		nr += zone_page_state_snapshot(zone, NR_ZONE_INACTIVE_ANON) +
 			zone_page_state_snapshot(zone, NR_ZONE_ACTIVE_ANON);
-
+	/*
+	 * If there are no reclaimable file-backed or anonymous pages,
+	 * ensure zones with sufficient free pages are not skipped.
+	 * This prevents zones like DMA32 from being ignored in reclaim
+	 * scenarios where they can still help alleviate memory pressure.
+	 */
+	if (nr == 0)
+		nr = zone_page_state_snapshot(zone, NR_FREE_PAGES);
 	return nr;
 }
However, should_reclaim_retry() function calls zone_reclaimable_pages to count free pages. When nr is 0, it double-counts NR_FREE_PAGES. This seems to cause inaccurate page statistics, right?
static inline bool
should_reclaim_retry(gfp_t gfp_mask, unsigned order,
		     struct alloc_context *ac, int alloc_flags,
		     bool did_some_progress, int *no_progress_loops)
{
......

		available = reclaimable = zone_reclaimable_pages(zone);
		available += zone_page_state_snapshot(zone, NR_FREE_PAGES);

		/*
		 * Would the allocation succeed if we reclaimed all
		 * reclaimable pages?
		 */
		wmark = __zone_watermark_ok(zone, order, min_wmark,
				ac->highest_zoneidx, alloc_flags, available);

compaction_zonelist_suitable() function has the same problem.
bool compaction_zonelist_suitable(struct alloc_context *ac, int order,
		int alloc_flags)
{
......
		available = zone_reclaimable_pages(zone) / order;
		available += zone_page_state_snapshot(zone, NR_FREE_PAGES);
		if (__compaction_suitable(zone, order, min_wmark_pages(zone),
					  ac->highest_zoneidx, available))

If this is problematic, can it be modified as follows:
diff --git a/mm/vmscan.c b/mm/vmscan.c
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -6417,7 +6417,7 @@ static bool allow_direct_reclaim(pg_data_t *pgdat)
                return true;
 
        for_each_managed_zone_pgdat(zone, pgdat, i, ZONE_NORMAL) {
-               if (!zone_reclaimable_pages(zone))
+               if (!zone_reclaimable_pages(zone) || !(zone_page_state_snapshot(zone, NR_FREE_PAGES)))
                        continue;

Signed-off-by: liuqiqi <liuqiqi@kylinos.cn>

Re: CVE-2024-57884 patch review feedback (https://lore.kernel.org/linux-cve-announce/2025011510-CVE-2024-57884-4cf8@gregkh/#R)

[Greg KH]

On Thu, Aug 07, 2025 at 09:05:15PM +0800, liuqiqi@kylinos.cn wrote:
> CVE-2024-57884  patch fixes  mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim() modify as follows
> @@ -342,7 +342,14 @@ unsigned long zone_reclaimable_pages(struct zone *zone)
>  	if (get_nr_swap_pages() > 0)
>  		nr += zone_page_state_snapshot(zone, NR_ZONE_INACTIVE_ANON) +
>  			zone_page_state_snapshot(zone, NR_ZONE_ACTIVE_ANON);
> -
> +	/*
> +	 * If there are no reclaimable file-backed or anonymous pages,
> +	 * ensure zones with sufficient free pages are not skipped.
> +	 * This prevents zones like DMA32 from being ignored in reclaim
> +	 * scenarios where they can still help alleviate memory pressure.
> +	 */
> +	if (nr == 0)
> +		nr = zone_page_state_snapshot(zone, NR_FREE_PAGES);
>  	return nr;
>  }
> However, should_reclaim_retry() function calls zone_reclaimable_pages to count free pages. When nr is 0, it double-counts NR_FREE_PAGES. This seems to cause inaccurate page statistics, right?
> static inline bool
> should_reclaim_retry(gfp_t gfp_mask, unsigned order,
> 		     struct alloc_context *ac, int alloc_flags,
> 		     bool did_some_progress, int *no_progress_loops)
> {
> ......
> 
> 		available = reclaimable = zone_reclaimable_pages(zone);
> 		available += zone_page_state_snapshot(zone, NR_FREE_PAGES);
> 
> 		/*
> 		 * Would the allocation succeed if we reclaimed all
> 		 * reclaimable pages?
> 		 */
> 		wmark = __zone_watermark_ok(zone, order, min_wmark,
> 				ac->highest_zoneidx, alloc_flags, available);
> 
> compaction_zonelist_suitable() function has the same problem.
> bool compaction_zonelist_suitable(struct alloc_context *ac, int order,
> 		int alloc_flags)
> {
> ......
> 		available = zone_reclaimable_pages(zone) / order;
> 		available += zone_page_state_snapshot(zone, NR_FREE_PAGES);
> 		if (__compaction_suitable(zone, order, min_wmark_pages(zone),
> 					  ac->highest_zoneidx, available))
> 
> If this is problematic, can it be modified as follows:
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -6417,7 +6417,7 @@ static bool allow_direct_reclaim(pg_data_t *pgdat)
>                 return true;
>  
>         for_each_managed_zone_pgdat(zone, pgdat, i, ZONE_NORMAL) {
> -               if (!zone_reclaimable_pages(zone))
> +               if (!zone_reclaimable_pages(zone) || !(zone_page_state_snapshot(zone, NR_FREE_PAGES)))
>                         continue;
> 
> Signed-off-by: liuqiqi <liuqiqi@kylinos.cn>

I have no idea what you are asking about or wishing to see change.
Please read the kernel documentation for how to send a proper patch.

thanks,

greg k-h

mm:fix duplicate accounting of free pages in should_reclaim_retry()

[liuqiqi]

In the zone_reclaimable_pages() function, if the page counts for NR_ZONE_INACTIVE_FILE, 
NR_ZONE_ACTIVE_FILE, NR_ZONE_INACTIVE_ANON, and NR_ZONE_ACTIVE_ANON are all zero, 
the function returns the number of free pages as the result.

In this case, when should_reclaim_retry() calculates reclaimable pages, 
it will inadvertently double-count the free pages in its accounting.

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 34410d24dc15..a9aaefdba7a2 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -393,14 +393,7 @@ unsigned long zone_reclaimable_pages(struct zone *zone)
        if (can_reclaim_anon_pages(NULL, zone_to_nid(zone), NULL))
                nr += zone_page_state_snapshot(zone, NR_ZONE_INACTIVE_ANON) +
                        zone_page_state_snapshot(zone, NR_ZONE_ACTIVE_ANON);
-       /*
-        * If there are no reclaimable file-backed or anonymous pages,
-        * ensure zones with sufficient free pages are not skipped.
-        * This prevents zones like DMA32 from being ignored in reclaim
-        * scenarios where they can still help alleviate memory pressure.
-        */
-       if (nr == 0)
-               nr = zone_page_state_snapshot(zone, NR_FREE_PAGES);
+
        return nr;
 }
 
@@ -6417,7 +6410,7 @@ static bool allow_direct_reclaim(pg_data_t *pgdat)
                return true;
 
        for_each_managed_zone_pgdat(zone, pgdat, i, ZONE_NORMAL) {
-               if (!zone_reclaimable_pages(zone))
+               if (!zone_reclaimable_pages(zone) && zone_page_state_snapshot(zone, NR_FREE_PAGES))
                        continue;
 
signed-off-by: liuqiqi <liuqiqi@kylinos.cn>

Re: mm:fix duplicate accounting of free pages in should_reclaim_retry()

[Greg KH]

On Mon, Aug 11, 2025 at 05:53:30PM +0800, liuqiqi@kylinos.cn wrote:
> In the zone_reclaimable_pages() function, if the page counts for NR_ZONE_INACTIVE_FILE, 
> NR_ZONE_ACTIVE_FILE, NR_ZONE_INACTIVE_ANON, and NR_ZONE_ACTIVE_ANON are all zero, 
> the function returns the number of free pages as the result.
> 
> In this case, when should_reclaim_retry() calculates reclaimable pages, 
> it will inadvertently double-count the free pages in its accounting.
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 34410d24dc15..a9aaefdba7a2 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -393,14 +393,7 @@ unsigned long zone_reclaimable_pages(struct zone *zone)
>         if (can_reclaim_anon_pages(NULL, zone_to_nid(zone), NULL))
>                 nr += zone_page_state_snapshot(zone, NR_ZONE_INACTIVE_ANON) +
>                         zone_page_state_snapshot(zone, NR_ZONE_ACTIVE_ANON);
> -       /*
> -        * If there are no reclaimable file-backed or anonymous pages,
> -        * ensure zones with sufficient free pages are not skipped.
> -        * This prevents zones like DMA32 from being ignored in reclaim
> -        * scenarios where they can still help alleviate memory pressure.
> -        */
> -       if (nr == 0)
> -               nr = zone_page_state_snapshot(zone, NR_FREE_PAGES);
> +
>         return nr;
>  }
>  
> @@ -6417,7 +6410,7 @@ static bool allow_direct_reclaim(pg_data_t *pgdat)
>                 return true;
>  
>         for_each_managed_zone_pgdat(zone, pgdat, i, ZONE_NORMAL) {
> -               if (!zone_reclaimable_pages(zone))
> +               if (!zone_reclaimable_pages(zone) && zone_page_state_snapshot(zone, NR_FREE_PAGES))
>                         continue;
>  
> signed-off-by: liuqiqi <liuqiqi@kylinos.cn>
> 


Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch does not have a Signed-off-by: line.  Please read the
  kernel file, Documentation/process/submitting-patches.rst and resend
  it after adding that line.  Note, the line needs to be in the body of
  the email, before the patch, not at the bottom of the patch or in the
  email signature.

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/process/submitting-patches.rst for what is needed in
  order to properly describe the change.

- You did not submit this patch to the proper subsystem and maintainers.

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/process/submitting-patches.rst for what a proper
  Subject: line should look like.

- It looks like you did not use your "real" name for the patch on either
  the Signed-off-by: line, or the From: line (both of which have to
  match).  Please read the kernel file,
  Documentation/process/submitting-patches.rst for how to do this
  correctly.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot