)]}' { "commit": "86ce3b3fe7e3b54c836775f62acff9f5218e166e", "tree": "109dd4beaac4cd378f07bef0a134402c33f54f9c", "parents": [ "0fef10a7f6de0be0a45692b281c21c4f2a206927" ], "author": { "name": "Baolin Wang", "email": "baolin.wang@linux.alibaba.com", "time": "Tue Mar 17 17:29:55 2026 +0800" }, "committer": { "name": "Angel Adetula", "email": "angeladetula@google.com", "time": "Mon Apr 27 17:06:43 2026 -0700" }, "message": "mm: filemap: fix nr_pages calculation overflow in filemap_map_pages()\n\ncommit f58df566524ebcdfa394329c64f47e3c9257516e upstream.\n\nWhen running stress-ng on my Arm64 machine with v7.0-rc3 kernel, I\nencountered some very strange crash issues showing up as \"Bad page state\":\n\n\"\n[ 734.496287] BUG: Bad page state in process stress-ng-env pfn:415735fb\n[ 734.496427] page: refcount:0 mapcount:1 mapping:0000000000000000 index:0x4cf316 pfn:0x415735fb\n[ 734.496434] flags: 0x57fffe000000800(owner_2|node\u003d1|zone\u003d2|lastcpupid\u003d0x3ffff)\n[ 734.496439] raw: 057fffe000000800 0000000000000000 dead000000000122 0000000000000000\n[ 734.496440] raw: 00000000004cf316 0000000000000000 0000000000000000 0000000000000000\n[ 734.496442] page dumped because: nonzero mapcount\n\"\n\nAfter analyzing this page’s state, it is hard to understand why the\nmapcount is not 0 while the refcount is 0, since this page is not where\nthe issue first occurred. By enabling the CONFIG_DEBUG_VM config, I can\nreproduce the crash as well and captured the first warning where the issue\nappears:\n\n\"\n[ 734.469226] page: refcount:33 mapcount:0 mapping:00000000bef2d187 index:0x81a0 pfn:0x415735c0\n[ 734.469304] head: order:5 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n[ 734.469315] memcg:ffff000807a8ec00\n[ 734.469320] aops:ext4_da_aops ino:100b6f dentry name(?):\"stress-ng-mmaptorture-9397-0-2736200540\"\n[ 734.469335] flags: 0x57fffe400000069(locked|uptodate|lru|head|node\u003d1|zone\u003d2|lastcpupid\u003d0x3ffff)\n......\n[ 734.469364] page dumped because: VM_WARN_ON_FOLIO((_Generic((page + nr_pages - 1),\nconst struct page *: (const struct folio *)_compound_head(page + nr_pages - 1), struct page *:\n(struct folio *)_compound_head(page + nr_pages - 1))) !\u003d folio)\n[ 734.469390] ------------[ cut here ]------------\n[ 734.469393] WARNING: ./include/linux/rmap.h:351 at folio_add_file_rmap_ptes+0x3b8/0x468,\nCPU#90: stress-ng-mlock/9430\n[ 734.469551] folio_add_file_rmap_ptes+0x3b8/0x468 (P)\n[ 734.469555] set_pte_range+0xd8/0x2f8\n[ 734.469566] filemap_map_folio_range+0x190/0x400\n[ 734.469579] filemap_map_pages+0x348/0x638\n[ 734.469583] do_fault_around+0x140/0x198\n......\n[ 734.469640] el0t_64_sync+0x184/0x188\n\"\n\nThe code that triggers the warning is: \"VM_WARN_ON_FOLIO(page_folio(page +\nnr_pages - 1) !\u003d folio, folio)\", which indicates that set_pte_range()\ntried to map beyond the large folio’s size.\n\nBy adding more debug information, I found that \u0027nr_pages\u0027 had overflowed\nin filemap_map_pages(), causing set_pte_range() to establish mappings for\na range exceeding the folio size, potentially corrupting fields of pages\nthat do not belong to this folio (e.g., page-\u003e_mapcount).\n\nAfter above analysis, I think the possible race is as follows:\n\nCPU 0 CPU 1\nfilemap_map_pages() ext4_setattr()\n //get and lock folio with old inode-\u003ei_size\n next_uptodate_folio()\n\n .......\n //shrink the inode-\u003ei_size\n i_size_write(inode, attr-\u003eia_size);\n\n //calculate the end_pgoff with the new inode-\u003ei_size\n file_end \u003d DIV_ROUND_UP(i_size_read(mapping-\u003ehost), PAGE_SIZE) - 1;\n end_pgoff \u003d min(end_pgoff, file_end);\n\n ......\n //nr_pages can be overflowed, cause xas.xa_index \u003e end_pgoff\n end \u003d folio_next_index(folio) - 1;\n nr_pages \u003d min(end, end_pgoff) - xas.xa_index + 1;\n\n ......\n //map large folio\n filemap_map_folio_range()\n ......\n //truncate folios\n truncate_pagecache(inode, inode-\u003ei_size);\n\nTo fix this issue, move the \u0027end_pgoff\u0027 calculation before\nnext_uptodate_folio(), so the retrieved folio stays consistent with the\nfile end to avoid \u0027nr_pages\u0027 calculation overflow. After this patch, the\ncrash issue is gone.\n\nBUG\u003db/506404832\nTEST\u003dpresubmit\nRELEASE_NOTE\u003dFixed CVE-2026-31648 in the Linux kernel.\n\ncos-patch: security-moderate\nLink: https://lkml.kernel.org/r/1cf1ac59018fc647a87b0dad605d4056a71c14e4.1773739704.git.baolin.wang@linux.alibaba.com\nFixes: 743a2753a02e (\"filemap: cap PTE range to be created to allowed zero fill in folio_map_range()\")\nChange-Id: I1e8a70bca0e16fff03ae0378d70bc8470d0df6e0\nSigned-off-by: Baolin Wang \u003cbaolin.wang@linux.alibaba.com\u003e\nReported-by: Yuanhe Shu \u003cxiangzao@linux.alibaba.com\u003e\nTested-by: Yuanhe Shu \u003cxiangzao@linux.alibaba.com\u003e\nAcked-by: Kiryl Shutsemau (Meta) \u003ckas@kernel.org\u003e\nAcked-by: David Hildenbrand (Arm) \u003cdavid@kernel.org\u003e\nCc: Christian Brauner \u003cbrauner@kernel.org\u003e\nCc: Daniel Gomez \u003cda.gomez@samsung.com\u003e\nCc: \"Darrick J. Wong\" \u003cdjwong@kernel.org\u003e\nCc: Dave Chinner \u003cdchinner@redhat.com\u003e\nCc: David Howells \u003cdhowells@redhat.com\u003e\nCc: Hannes Reinecke \u003chare@suse.de\u003e\nCc: Lorenzo Stoakes (Oracle) \u003cljs@kernel.org\u003e\nCc: Luis Chamberalin \u003cmcgrof@kernel.org\u003e\nCc: Matthew Wilcox (Oracle) \u003cwilly@infradead.org\u003e\nCc: Pankaj Raghav \u003cp.raghav@samsung.com\u003e\nCc: \u003cstable@vger.kernel.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\nSigned-off-by: Kernel CVE Triage Automation \u003ccloud-image-kernel-cve-triage-automation@prod.google.com\u003e\nReviewed-on: https://cos-review.googlesource.com/c/third_party/kernel/+/146643\nReviewed-by: Robert Kolchmeyer \u003crkolchmeyer@google.com\u003e\nTested-by: Cusky Presubmit Bot \u003cpresubmit@cos-infra-prod.iam.gserviceaccount.com\u003e\nReviewed-by: Angel Adetula \u003cangeladetula@google.com\u003e\n", "tree_diff": [ { "type": "modify", "old_id": "d8d9c0f0beb6d95d18e9c6f83b334e5ae6795bc7", "old_mode": 33188, "old_path": "mm/filemap.c", "new_id": "dc6a8451917f1e92285137885691f52cf2e15a70", "new_mode": 33188, "new_path": "mm/filemap.c" } ] }