linux-kernel - Re: [PATCH v4 2/3] mm: handle poisoning of pfn without struct pages

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 for Android: free password hash cracker in your pocket

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

Message-ID:
 <MW4PR12MB7213976611F767842380FB56B0FAA@MW4PR12MB7213.namprd12.prod.outlook.com>
Date: Wed, 29 Oct 2025 03:15:08 +0000
From: Ankit Agrawal <ankita@...dia.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: Aniket Agashe <aniketa@...dia.com>, Vikram Sethi <vsethi@...dia.com>,
	Jason Gunthorpe <jgg@...dia.com>, Matt Ochs <mochs@...dia.com>, Shameer
 Kolothum <skolothumtho@...dia.com>, "linmiaohe@...wei.com"
	<linmiaohe@...wei.com>, "nao.horiguchi@...il.com" <nao.horiguchi@...il.com>,
	"david@...hat.com" <david@...hat.com>, "lorenzo.stoakes@...cle.com"
	<lorenzo.stoakes@...cle.com>, "Liam.Howlett@...cle.com"
	<Liam.Howlett@...cle.com>, "vbabka@...e.cz" <vbabka@...e.cz>,
	"rppt@...nel.org" <rppt@...nel.org>, "surenb@...gle.com" <surenb@...gle.com>,
	"mhocko@...e.com" <mhocko@...e.com>, "tony.luck@...el.com"
	<tony.luck@...el.com>, "bp@...en8.de" <bp@...en8.de>, "rafael@...nel.org"
	<rafael@...nel.org>, "guohanjun@...wei.com" <guohanjun@...wei.com>,
	"mchehab@...nel.org" <mchehab@...nel.org>, "lenb@...nel.org"
	<lenb@...nel.org>, "kevin.tian@...el.com" <kevin.tian@...el.com>,
	"alex@...zbot.org" <alex@...zbot.org>, Neo Jia <cjia@...dia.com>, Kirti
 Wankhede <kwankhede@...dia.com>, "Tarun Gupta (SW-GPU)"
	<targupta@...dia.com>, Zhi Wang <zhiw@...dia.com>, Dheeraj Nigam
	<dnigam@...dia.com>, Krishnakant Jaju <kjaju@...dia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-edac@...r.kernel.org"
	<linux-edac@...r.kernel.org>, "Jonathan.Cameron@...wei.com"
	<Jonathan.Cameron@...wei.com>, "ira.weiny@...el.com" <ira.weiny@...el.com>,
	"Smita.KoralahalliChannabasappa@....com"
	<Smita.KoralahalliChannabasappa@....com>, "u.kleine-koenig@...libre.com"
	<u.kleine-koenig@...libre.com>, "peterz@...radead.org"
	<peterz@...radead.org>, "linux-acpi@...r.kernel.org"
	<linux-acpi@...r.kernel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH v4 2/3] mm: handle poisoning of pfn without struct pages

Thanks Andrew for the comments.

>> +int register_pfn_address_space(struct pfn_address_space *pfn_space)
>> +{
>> +     if (!pfn_space)
>> +             return -EINVAL;
>
> I suggest this be removed - make register_pfn_address_space(NULL)
> illegal and let the punishment be an oops.

Yes, will remove it.

>> +static void add_to_kill_pfn(struct task_struct *tsk,
>> +                         struct vm_area_struct *vma,
>> +                         struct list_head *to_kill,
>> +                         unsigned long pfn)
>> +{
>> +     struct to_kill *tk;
>> +
>> +     tk = kmalloc(sizeof(*tk), GFP_ATOMIC);
>> +     if (!tk)
>> +             return;
>
> This is unfortunate.  GFP_ATOMIC is unreliable and we silently behave
> as if it worked OK.

Got it. I'll mark this as a failure case.


> We could play games here to make the GFP_ATOMIC allocation unnecessary,
> but nasty.  Allocate the to_kill* outside the rcu_read_lock, pass that
> pointer into add_to_kill_pfn().  If add_to_kill_pfn()'s
> kmalloc(GFP_ATOMIC) failed, add_to_kill_pfn() can then consume the
> caller's to_kill*.  Then the caller can drop the lock, allocate a new
> to_kill* then restart the scan.  And teach add_to_kill_pfn() to not
> re-add tasks which are already on the list.  Ugh.
>
> At the very very least we should tell the user that the kernel goofed
> and that one of their processes won't be getting killed.

Thanks for the suggestion. As mentioned above I'll mark the kmalloc
allocation error as a failure and can put a log message there.

>> +     scoped_guard(mutex, &pfn_space_lock) {
>> +             bool mf_handled = false;
>> +
>> +             /*
>> +              * Modules registers with MM the address space mapping to the device memory they
>> +              * manage. Iterate to identify exactly which address space has mapped to this
>> +              * failing PFN.
>
> We're quite lenient about >80 columns nowadays, but overflowing 80 for
> a block comment is rather needless.

Yes. Since it passed through the strict checkpatch.pl check, I didn't notice.
I'll fix it.