linux-kernel - Re: [REGRESSION] NULL pointer dereference on ARM (AT91SAM9G25) during compaction

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: <5d50d714-197f-44c0-94e0-ff70ee51e866@bytedance.com>
Date: Tue, 11 Feb 2025 11:45:19 +0800
From: Qi Zheng <zhengqi.arch@...edance.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Ezra Buehler <ezra@...yb.ch>, linux-mm@...ck.org,
 Andrew Morton <akpm@...ux-foundation.org>,
 David Hildenbrand <david@...hat.com>,
 "Mike Rapoport (Microsoft)" <rppt@...nel.org>,
 Muchun Song <muchun.song@...ux.dev>, Vlastimil Babka <vbabka@...e.cz>,
 Ryan Roberts <ryan.roberts@....com>,
 "Vishal Moola (Oracle)" <vishal.moola@...il.com>,
 Hugh Dickins <hughd@...gle.com>, Matthew Wilcox <willy@...radead.org>,
 Peter Xu <peterx@...hat.com>, Nicolas Ferre <nicolas.ferre@...rochip.com>,
 Alexandre Belloni <alexandre.belloni@...tlin.com>,
 Claudiu Beznea <claudiu.beznea@...on.dev>,
 open list <linux-kernel@...r.kernel.org>,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [REGRESSION] NULL pointer dereference on ARM (AT91SAM9G25) during
 compaction

Hi Russell,

On 2025/2/11 01:03, Russell King (Oracle) wrote:
> On Mon, Feb 10, 2025 at 05:49:38PM +0100, Ezra Buehler wrote:
>> When running vanilla Linux 6.13 or newer (6.14-rc2) on the
>> AT91SAM9G25-based GARDENA smart Gateway, we are seeing a NULL pointer
>> dereference resulting in a kernel panic. The culprit seems to be commit
>> fc9c45b71f43 ("arm: adjust_pte() usepte_offset_map_rw_nolock()").
>> Reverting the commit apparently fixes the issue.
> 
> The blamed commit is buggy:
> 
> arch/arm/include/asm/tlbflush.h:
> #define update_mmu_cache(vma, addr, ptep) \
>          update_mmu_cache_range(NULL, vma, addr, ptep, 1)
> 
> So vmf can be NULL. This didn't used to matter before this commit,
> because vmf was not used by ARM's update_mmu_cache_range(). However,
> the commit introduced a dereference of it, which now causes a NULL
> point dereference.
> 
> Not sure what the correct solution is, but at a guess, both:
> 
> 	if (ptl != vmf->ptl)
> 
> need to become:
> 
> 	if (!vmf || ptl != vmf->ptl)

No, we can't do that, because without using split PTE locks, we would
use shared mm->page_table_lock, which would create a deadlock.

But it seems that we cannot simply bring back do_pte_lock() and
do_pte_unlock()? In make_coherent(), we traverse the vmas and exclude
the same vma, but different vmas may also map to the same PTE page,
right? In this case, we still cannot directly hold the pte lock.
But this part of code is quite old, maybe I missed something?

Thanks,
Qi

> 
> but I haven't checked wha tthe locking context actually is here
> (I've been out of MM stuff too long to know this off the top of my
> head.)
>