On Sun, May 17, 2026 at 02:17:18AM +0100, Matthew Wilcox wrote:
> On Sun, May 17, 2026 at 01:59:41AM +0100, Pedro Falcato wrote:
> > On Sun, May 17, 2026 at 12:07:05AM +0100, Matthew Wilcox wrote:
> > > On Sat, May 16, 2026 at 07:21:26PM +0100, Pedro Falcato wrote:
> > > > +static bool may_write_to_page(struct page *page, struct address_space 
> > > > **plast)
> > > > +{
> > > > +       struct folio *folio = page_folio(page);
> > > > +       struct address_space *mapping, *last = *plast;
> > > > +       struct inode *inode;
> > > > +       bool may = false;
> > > > +
> > > > +       if (!READ_ONCE(sysctl_splice_needs_write))
> > > > +               return true;
> > > > +       /*
> > > > +        * Always fine to write to anon folios.
> > > > +        */
> > > > +       if (folio_test_anon(folio))
> > > > +               return true;
> > > 
> > > What about KSM?  It's not something we've seen attacked yet, but it'd be
> > > pretty nasty to be able to change a KSM page in another process.
> > 
> > It's my understanding that only anon pages can be KSM'd, and KSM still keeps
> > the FOLIO_MAPPING_ANON bit set. So folio_test_anon() should still test true
> > for those.
> 
> I think you misunderstood what I meant.  If we have a buggy user which
> can write to read-only file pages, then it should also be prevented from
> writing to KSM pages.

Hmm, I see. Are you suggesting we unshare KSM pages here? Or just straight
up reject them?

Rejecting would be relatively sane if only we had access to the VMA here
(in normal GUP), testing on folio_test_ksm() is less robust :/

-- 
Pedro

Reply via email to