--------------------------------
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.232.135.74 listed in list.dnswl.org]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
SpamTally: Final spam score: 5


--=-a628iJZ2IuWGJ/zSUBkp
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-01-15 at 17:49 +0100, Greg Kroah-Hartman wrote:
> 5.10-stable review patch.  If anyone has any objections, please let me kn=
ow.
>=20
> ------------------
>=20
> From: Chuck Lever <chuck.lever@oracle.com>
>=20
> [ Upstream commit 913f7cf77bf14c13cfea70e89bcb6d0b22239562 ]
>=20
> An NFSv4 client that sets an ACL with a named principal during file
> creation retrieves the ACL afterwards, and finds that it is only a
> default ACL (based on the mode bits) and not the ACL that was
> requested during file creation. This violates RFC 8881 section
> 6.4.1.3: "the ACL attribute is set as given".
>=20
> The issue occurs in nfsd_create_setattr(). On 6.1.y, the check to
> determine whether nfsd_setattr() should be called is simply
> "iap->ia_valid", which only accounts for iattr changes. When only
> an ACL is present (and no iattr fields are set), nfsd_setattr() is
> skipped and the POSIX ACL is never applied to the inode.
>=20
> Subsequently, when the client retrieves the ACL, the server finds
> no POSIX ACL on the inode and returns one generated from the file's
> mode bits rather than returning the originally-specified ACL.
>=20
> Reported-by: Aurelien Couderc <aurelien.couderc2002@gmail.com>
> Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
> Cc: stable@vger.kernel.org
> [ cel: Adjust nfsd_create_setattr() instead of nfsd_attrs_valid() ]
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>

Would it make sense to also backport:

commit 442d27ff09a218b61020ab56387dbc508ad6bfa6
Author: Stephen Smalley <stephen.smalley.work@gmail.com>
Date:   Fri May 3 09:09:06 2024 -0400

    nfsd: set security label during create operations

?  It seems like that's fixing a similar kind of bug, and would also
make the upstream version of this apply cleanly.

Ben.

> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  fs/nfsd/vfs.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>=20
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -1335,7 +1335,7 @@ nfsd_create_setattr(struct svc_rqst *rqs
>  	 * Callers expect new file metadata to be committed even
>  	 * if the attributes have not changed.
>  	 */
> -	if (iap->ia_valid)
> +	if (iap->ia_valid || attrs->na_pacl || attrs->na_dpacl)
>  		status =3D nfsd_setattr(rqstp, resfhp, attrs, 0, (time64_t)0);
>  	else
>  		status =3D nfserrno(commit_metadata(resfhp));
>=20
>=20

--=20
Ben Hutchings
Larkinson's Law: All laws are basically false.

--=-a628iJZ2IuWGJ/zSUBkp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmltK2MACgkQ57/I7JWG
EQnWiQ/8CypNefSG2tAmnSiFaxRfMUtN6kIJbgF7PyPSoVbrpZerXWL6fd99mAxb
e0HqdNdDEDfwLeL0l+0Rci+JANyiEy9vN0+gVieRuRGYlKEQ0mFL1lqsa4KuN5Q3
wwYnJTZPu4sGVusVYLnIQMAwaFpv40sSbAiSVx5IFcIrPtkquoY82ZeyMBNj1Fz6
Efx0Kt6qqM7iBbMhDw75RR3FPtw4ywopnHh0z3JgWPx7dE4TKP2x8mJH8BwOvzxu
nBU93uoDlTCfA4fGkGEzkjRRsHhJ3KYlpPligLavxJRZh17jMtxK3geG7DByy4Fq
29SOlJQC+JRgGnALiHbQr0DwFBbI9CszQksIhihLoP9VmXh7NOblldf5LYpRRD3h
HTJfQY7ThIGIKtFSACjtYRZMlWEl+vsdbTu/HR8vDeFb5ugJBBTvYojzJZKxe2r5
8IJX/iKLqPAKht33zqL504vAFSYuwn5OZKh0gv6wpLXbnYwiCXCE5CDYiWCrWcZn
NYj6DxrUN14AS+74TY1ZZOix///S3yQOo/UFjvSCy4h0Gk8tL7ZYSfcit4QTHPws
+UrIzBdb6cQmcbmwsZODpHWqx3xnChzE3SxqgOxt+tU8AUwAxasQoJ7kgaz4itkA
Hh4ga7hMj6ezHtaPR0MikBA1qGcVGchGTv3pdUBWZ97dCD6tn9s=
=gc7W
-----END PGP SIGNATURE-----

--=-a628iJZ2IuWGJ/zSUBkp--


From - Sun Jan 18 18:57:39 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-210234-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id QMrmCaEsbWmK2hoAYBR5ng
	(envelope-from <stable+bounces-210234-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Sun, 18 Jan 2026 18:55:29 +0000
Return-path: <stable+bounces-210234-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Sun, 18 Jan 2026 18:55:29 +0000
Received: from sin.lore.kernel.org ([104.64.211.4])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-210234-hi=josie.lol@vger.kernel.org>)
	id 1vhXvs-000000084uC-1ENS
	for hi@josie.lol;
	Sun, 18 Jan 2026 18:55:29 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sin.lore.kernel.org (Postfix) with ESMTP id A51CD3002504
	for <hi@josie.lol>; Sun, 18 Jan 2026 18:55:21 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id F11BC50095A;
	Sun, 18 Jan 2026 18:55:17 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="aTo8FQsG";
	dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="tI3bhuzM"
X-Original-To: stable@vger.kernel.org
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0471C1A316E;
	Sun, 18 Jan 2026 18:55:15 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=205.220.177.32
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1768762517; cv=fail; b=QlEXjAgqrjWHENWl0BmyzrGdSjBW1TBXuo4IIsS8RTPBqzyPjjj8NYMeotuBLTviail/+S+YB+OZN5QIEPx8B6xySxr1oXDsaEfuQDt1o8YSPU8xD+D2jDNN1qIR4uGoZPp0mgszjrupO2AlvRVX6hRxQCeWHXIpMrW/RIla+6U=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1768762517; c=relaxed/simple;
	bh=A83VKrsYj6vgX60eAaYzlIsBCrBWxxCZrFf7dYRWRC4=;
	h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To:
	 Content-Type:MIME-Version; b=kuBsGYIj46i+BaSJKaM1Q3nt4+fPklKnMI6E9fyq/ygnkVinGHuLsWMlmbOQO2xUS7duMuzvsPfv+VF9XcnKyIeZDEomVFRaLYtSgEUmOmg7/vzVdtD6pPMbqpt7FvkSd4/DbWUvB1G7PerLTJ24SrC1AnHYiqsZpsIMFCf/noo=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=aTo8FQsG; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b=tI3bhuzM; arc=fail smtp.client-ip=205.220.177.32
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com
Received: from pps.filterd (m0246630.ppops.net [127.0.0.1])
	by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 60IIhm0A4049649;
	Sun, 18 Jan 2026 18:55:05 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2025-04-25; bh=isqXqMS/hRttLD2aWCrrJFRAadCgrnyg979fUl0ALn0=; b=
	aTo8FQsGjghEG9rBlykKITVPISg/fgEQybDSV3eiNjO3rwtwmfEAFwgSzgDP94LV
	zqoJsi+Z3ekBiLfxR7E4p0y4Nz4z25j3a4Rwk38E5it49GUtELS9QmT3reUChZ5J
	JhqGyOaIooCU/5dQcjgDs9y7EC2i7XHrN6n7tuPQFqpgEUdW0SQX2EgYM8Thb1Io
	ZiXg6yY