linux-kernel - Re: [PATCH] mm, hugetlb: Reset mapping to TAIL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ab6d9bc7-4e6a-4604-9dca-44b13ce409b6@redhat.com>
Date: Tue, 15 Apr 2025 09:23:43 +0200
From: David Hildenbrand <david@...hat.com>
To: Oscar Salvador <osalvador@...e.de>,
 Andrew Morton <akpm@...ux-foundation.org>
Cc: Muchun Song <muchun.song@...ux.dev>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, Vlastimil Babka <vbabka@...e.cz>,
 Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH] mm, hugetlb: Reset mapping to TAIL_MAPPING before
 restoring vmemmap

On 15.04.25 07:47, Oscar Salvador wrote:
> commit 4eeec8c89a0c ("mm: move hugetlb specific things in folio to page[3]")
> shifted hugetlb specific stuff, and now mapping overlaps _hugetlb_cgroup field.
> 
> _hugetlb_cgroup is set to NULL when preparing the hugetlb page in
> init_new_hugetlb_folio().
> For a better picture, this is page->mapping before and after the comming
> for the first three tail pages:
> 
> before:
> page: fffff51a44358040  0000000000000000
> page: fffff51a44358080  0000000000000000
> page: fffff51a443580c0  dead000000000400
> 
> after:
> page: fffff1f0042b0040  0000000000000000
> page: fffff1f0042b0080  fffff1f0042b0090
> page: fffff1f0042b00c0  0000000000000000
> 
> Tail#2 has fffff1f0042b0090 because of the _deferred_list initialization,
> which was also shifted, but that is not a problem.
> 
> For HVO, upon restoring that gets copied in some tail pages (reset_struct_pages)
> and so those tail pages will not have TAIL_MAPPING set and the check
> in free_tail_page_prepare() will fail:
> 
>   kernel: BUG: Bad page state in process kworker/0:3  pfn:10ac40
>   kernel: page does not match folio
>   kernel: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10ac40
>   kernel: flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
>   kernel: raw: 0017ffffc0000000 fffff1f0042b0000 0000000000000000 0000000000000000
>   kernel: raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
>   kernel: page dumped because: corrupted mapping in tail page
> 
> Reset _hugetlb_cgroup to TAIL_MAPPING before restoring so tail pages have the
> right value.

Hi,

To handle that for ordinary hugtlb alloc/free I added in that patch in free_tail_page_prepare():

	case 3:
		/* the third tail page: hugetlb specifics overlap ->mappings */
		if (IS_ENABLED(CONFIG_HUGETLB_PAGE))
			break;
		fallthrough;
	default:
		if (page->mapping != TAIL_MAPPING) {
			bad_page(page, "corrupted mapping in tail page");
			goto out;
		}
		break;
	}

Now I am confused why that check doesn't catch that?

Apparently only a problem with HVO? Because I recall testing the ordinary alloc/free.

-- 
Cheers,

David / dhildenb