linux-kernel - Re: [PATCH v2 1/3] Fix userfaultfd_api to return EINVAL as expected

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: <Zng-rfCPvSaGvL7p@x1n>
Date: Sun, 23 Jun 2024 11:26:37 -0400
From: Peter Xu <peterx@...hat.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Audra Mitchell <audra@...hat.com>, viro@...iv.linux.org.uk,
	brauner@...nel.org, jack@...e.cz, aarcange@...hat.com,
	rppt@...ux.vnet.ibm.com, shli@...com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, shuah@...nel.org,
	linux-kselftest@...r.kernel.org, raquini@...hat.com
Subject: Re: [PATCH v2 1/3] Fix userfaultfd_api to return EINVAL as expected

On Fri, Jun 21, 2024 at 06:03:30PM -0700, Andrew Morton wrote:
> On Fri, 21 Jun 2024 14:12:22 -0400 Audra Mitchell <audra@...hat.com> wrote:
> 
> > Currently if we request a feature that is not set in the Kernel
> > config we fail silently and return all the available features. However,
> > the man page indicates we should return an EINVAL.
> > 
> > We need to fix this issue since we can end up with a Kernel warning
> > should a program request the feature UFFD_FEATURE_WP_UNPOPULATED on
> > a kernel with the config not set with this feature.
> > 
> >  [  200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660
> >  [  200.820738] Modules linked in:
> >  [  200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8
> >  [  200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022
> >  [  200.885052] RIP: 0010:zap_pte_range+0x43d/0x660
> > 
> > Fixes: e06f1e1dd499 ("userfaultfd: wp: enabled write protection in userfaultfd API")
> 
> A userspace-triggerable WARN is bad.  I added cc:stable to this.

Andrew,

Note that this change may fix a WARN, but it may also start to break
userspace which might be worse if it happens, IMHO.  I forgot to mention
that here, but only mentioned that in v1, and from that POV not copying
stable seems the right thing.

https://lore.kernel.org/all/ZjuIEH8TW2tWcqXQ@x1n/

        In summary: I think we can stick with Fixes on e06f1e1dd499, but we
        don't copy stable.  The major reason we don't copy stable here is
        not only about complexity of such backport, but also that there can
        be apps trying to pass in unsupported bits (even if the kernel
        didn't support it) but keep using MISSING mode only, then we
        shouldn't fail them easily after a stable upgrade.  Just smells
        dangerous to backport.

I'm not sure what's the best solution for this.  A sweet spot might be that
we start to fix it in new kernels only but not stable ones.

Thanks,

-- 
Peter Xu