linux-kernel - Re: [PATCH v2 4/4] mm: page_table_check: Ensure user pages are not slab 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 16 May 2023 22:17:02 +0800
From:   Ruihan Li <lrh2000@....edu.cn>
To:     David Hildenbrand <david@...hat.com>
Cc:     Pasha Tatashin <pasha.tatashin@...een.com>, linux-mm@...ck.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        Matthew Wilcox <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Christoph Hellwig <hch@...radead.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        syzbot+fcf1a817ceb50935ce99@...kaller.appspotmail.com,
        stable@...r.kernel.org, Ruihan Li <lrh2000@....edu.cn>
Subject: Re: [PATCH v2 4/4] mm: page_table_check: Ensure user pages are not
 slab pages

On Tue, May 16, 2023 at 02:54:04PM +0200, David Hildenbrand wrote:
> 
> On 16.05.23 13:51, Ruihan Li wrote:
> > On Mon, May 15, 2023 at 12:28:54PM -0400, Pasha Tatashin wrote:
> > > 
> > > On Mon, May 15, 2023 at 9:10 AM Ruihan Li <lrh2000@....edu.cn> wrote:
> > > > 
> > > > The current uses of PageAnon in page table check functions can lead to
> > > > type confusion bugs between struct page and slab [1], if slab pages are
> > > > accidentally mapped into the user space. This is because slab reuses the
> > > > bits in struct page to store its internal states, which renders PageAnon
> > > > ineffective on slab pages.
> > > > 
> > > > Since slab pages are not expected to be mapped into the user space, this
> > > > patch adds BUG_ON(PageSlab(page)) checks to make sure that slab pages
> > > > are not inadvertently mapped. Otherwise, there must be some bugs in the
> > > > kernel.
> > > > 
> > > > Reported-by: syzbot+fcf1a817ceb50935ce99@...kaller.appspotmail.com
> > > > Closes: https://lore.kernel.org/lkml/000000000000258e5e05fae79fc1@google.com/ [1]
> > > > Fixes: df4e817b7108 ("mm: page table check")
> > > > Cc: <stable@...r.kernel.org> # 5.17
> > > > Signed-off-by: Ruihan Li <lrh2000@....edu.cn>
> > > 
> > > Acked-by: Pasha Tatashin <pasha.tatashin@...een.com>
> > > 
> > > I would also update order in mm/memory.c
> > > static int validate_page_before_insert(struct page *page)
> > > {
> > > if (PageAnon(page) || PageSlab(page) || page_has_type(page))
> > > 
> > > It is not strictly a bug there, as it works by accident, but
> > > PageSlab() should go before PageAnon(), because without checking if
> > > this is PageSlab() we should not be testing for PageAnon().
> > 
> > Right. Perhaps it would be better to send another patch for this
> > separately.
> 
> Probably not really worth it IMHO. With PageSlab() we might have PageAnon()
> false-positives. Either will take the same path here ...

Well, I'm not against that. If just fixing this one doesn't look
worthwhile, I'm not sure if anyone wishes to find and clean up all these
"misuses" altogether, though that's certainly a low-priority task if
nothing is actually broken.

> 
> On a related note, stable_page_flags() checks PageKsm()/PageAnon() without
> caring about PageSlab().
> 
> At least it's just a debugging interface and will indicate KPF_SLAB in any
> case as well ...

I just went through that function quickly, and found that PageHuge also
seems to be accessing non-existent fields (folio->_folio_dtor) on slab
pages. Again, nothing is really broken.

> 
> -- 
> Thanks,
> 
> David / dhildenb

Thanks,
Ruihan Li