The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 168f912893407a5acb798a4a58613b5f1f98c717 Mon Sep 17 00:00:00 2001
From: Christian Brauner <brauner(a)kernel.org>
Date: Mon, 13 Jun 2022 13:15:17 +0200
Subject: [PATCH] fs: account for group membership
When calling setattr_prepare() to determine the validity of the
attributes the ia_{g,u}id fields contain the value that will be written
to inode->i_{g,u}id. This is exactly the same for idmapped and
non-idmapped mounts and allows callers to pass in the values they want
to see written to inode->i_{g,u}id.
When group ownership is changed a caller whose fsuid owns the inode can
change the group of the inode to any group they are a member of. When
searching through the caller's groups we need to use the gid mapped
according to the idmapped mount otherwise we will fail to change
ownership for unprivileged users.
Consider a caller running with fsuid and fsgid 1000 using an idmapped
mount that maps id 65534 to 1000 and 65535 to 1001. Consequently, a file
owned by 65534:65535 in the filesystem will be owned by 1000:1001 in the
idmapped mount.
The caller now requests the gid of the file to be changed to 1000 going
through the idmapped mount. In the vfs we will immediately map the
requested gid to the value that will need to be written to inode->i_gid
and place it in attr->ia_gid. Since this idmapped mount maps 65534 to
1000 we place 65534 in attr->ia_gid.
When we check whether the caller is allowed to change group ownership we
first validate that their fsuid matches the inode's uid. The
inode->i_uid is 65534 which is mapped to uid 1000 in the idmapped mount.
Since the caller's fsuid is 1000 we pass the check.
We now check whether the caller is allowed to change inode->i_gid to the
requested gid by calling in_group_p(). This will compare the passed in
gid to the caller's fsgid and search the caller's additional groups.
Since we're dealing with an idmapped mount we need to pass in the gid
mapped according to the idmapped mount. This is akin to checking whether
a caller is privileged over the future group the inode is owned by. And
that needs to take the idmapped mount into account. Note, all helpers
are nops without idmapped mounts.
New regression test sent to xfstests.
Link: https://github.com/lxc/lxd/issues/10537
Link: https://lore.kernel.org/r/20220613111517.2186646-1-brauner@kernel.org
Fixes: 2f221d6f7b88 ("attr: handle idmapped mounts")
Cc: Seth Forshee <sforshee(a)digitalocean.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Aleksa Sarai <cyphar(a)cyphar.com>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: stable(a)vger.kernel.org # 5.15+
CC: linux-fsdevel(a)vger.kernel.org
Reviewed-by: Seth Forshee <sforshee(a)digitalocean.com>
Signed-off-by: Christian Brauner (Microsoft) <brauner(a)kernel.org>
diff --git a/fs/attr.c b/fs/attr.c
index 66899b6e9bd8..dbe996b0dedf 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -61,9 +61,15 @@ static bool chgrp_ok(struct user_namespace *mnt_userns,
const struct inode *inode, kgid_t gid)
{
kgid_t kgid = i_gid_into_mnt(mnt_userns, inode);
- if (uid_eq(current_fsuid(), i_uid_into_mnt(mnt_userns, inode)) &&
- (in_group_p(gid) || gid_eq(gid, inode->i_gid)))
- return true;
+ if (uid_eq(current_fsuid(), i_uid_into_mnt(mnt_userns, inode))) {
+ kgid_t mapped_gid;
+
+ if (gid_eq(gid, inode->i_gid))
+ return true;
+ mapped_gid = mapped_kgid_fs(mnt_userns, i_user_ns(inode), gid);
+ if (in_group_p(mapped_gid))
+ return true;
+ }
if (capable_wrt_inode_uidgid(mnt_userns, inode, CAP_CHOWN))
return true;
if (gid_eq(kgid, INVALID_GID) &&
@@ -123,12 +129,20 @@ int setattr_prepare(struct user_namespace *mnt_userns, struct dentry *dentry,
/* Make sure a caller can chmod. */
if (ia_valid & ATTR_MODE) {
+ kgid_t mapped_gid;
+
if (!inode_owner_or_capable(mnt_userns, inode))
return -EPERM;
+
+ if (ia_valid & ATTR_GID)
+ mapped_gid = mapped_kgid_fs(mnt_userns,
+ i_user_ns(inode), attr->ia_gid);
+ else
+ mapped_gid = i_gid_into_mnt(mnt_userns, inode);
+
/* Also check the setgid bit! */
- if (!in_group_p((ia_valid & ATTR_GID) ? attr->ia_gid :
- i_gid_into_mnt(mnt_userns, inode)) &&
- !capable_wrt_inode_uidgid(mnt_userns, inode, CAP_FSETID))
+ if (!in_group_p(mapped_gid) &&
+ !capable_wrt_inode_uidgid(mnt_userns, inode, CAP_FSETID))
attr->ia_mode &= ~S_ISGID;
}
After patch ddbd89deb7d3 ("swiotlb: fix info leak with DMA_FROM_DEVICE"),
swiotlb_bounce will be called in swiotlb_tbl_map_single unconditionally.
This requires that the physical address must be valid, which is not always
true on stable-4.19 or earlier version.
On stable-4.19, swiotlb_alloc_buffer will call swiotlb_tbl_map_single with
orig_addr equal to zero, which cause such a panic:
Unable to handle kernel paging request at virtual address ffffb77a40000000
...
pc : __memcpy+0x100/0x180
lr : swiotlb_bounce+0x74/0x88
...
Call trace:
__memcpy+0x100/0x180
swiotlb_tbl_map_single+0x2c8/0x338
swiotlb_alloc+0xb4/0x198
__dma_alloc+0x84/0x1d8
...
On stable-4.9 and stable-4.14, swiotlb_alloc_coherent wille call map_single
with orig_addr equal to zero, which can cause same panic.
Fix this by skipping swiotlb_bounce when orig_addr is zero.
Fixes: ddbd89deb7d3 ("swiotlb: fix info leak with DMA_FROM_DEVICE")
Signed-off-by: Liu Shixin <liushixin2(a)huawei.com>
---
lib/swiotlb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index bdc2b89870e3..e162cb464ee4 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -607,7 +607,8 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
* unconditional bounce may prevent leaking swiotlb content (i.e.
* kernel memory) to user-space.
*/
- swiotlb_bounce(orig_addr, tlb_addr, size, DMA_TO_DEVICE);
+ if (orig_addr)
+ swiotlb_bounce(orig_addr, tlb_addr, size, DMA_TO_DEVICE);
return tlb_addr;
}
EXPORT_SYMBOL_GPL(swiotlb_tbl_map_single);
--
2.25.1
Hi Greg and Sasha,
Please apply commit 1e70212e0315 ("hinic: Replace memcpy() with direct
assignment") to 5.18. It fixes a warning visible when building arm64 and
x86_64 allmodconfig with clang 14 and newer (and possibly other
architectures but I didn't check). This will allow CONFIG_WERROR to
remain enabled when building arm64 and x86_64 kernels with clang on 5.15
and 5.18 (other architectures and newer versions are getting there).
This change shouldn't be problematic in older kernels but the warning it
fixes won't be visible without the new FORTIFY_SOURCE changes that
landed in 5.18, so I wouldn't worry about backporting it further.
Cheers,
Nathan
Hi Greg and Sasha,
This is the 5.15.y series corresponding to the 5.10.y set that Amir
recently sent out [1]. These patches have been tested on both 5.10.y
and 5.15.y with no regressions found. This series has been ACK'ed by
the XFS developers for 5.15.y and are ready for 5.15 stable.
Best,
Leah
Changes from [v3]:
- Post to stable
Changes from [v2]:
- Drop SGID fix [2]
- Added Acks from Darrick for remaining patches
Changes from [v1]:
- Increased testing
- Reduced patch set to overlap with 5.10 patches
[v1]: https://lore.kernel.org/linux-xfs/20220603184701.3117780-1-leah.rumancik@gm…
[v2]: https://lore.kernel.org/linux-xfs/20220616182749.1200971-1-leah.rumancik@gm…
[v3]: https://lore.kernel.org/linux-xfs/20220623203641.1710377-1-leah.rumancik@gm…
[1] https://lore.kernel.org/linux-xfs/20220627065140.2798412-1-amir73il@gmail.c…
[2] https://lore.kernel.org/linux-xfs/20220617100641.1653164-12-amir73il@gmail.…
Brian Foster (1):
xfs: punch out data fork delalloc blocks on COW writeback failure
Darrick J. Wong (3):
xfs: remove all COW fork extents when remounting readonly
xfs: prevent UAF in xfs_log_item_in_current_chkpt
xfs: only bother with sync_filesystem during readonly remount
Dave Chinner (1):
xfs: check sb_meta_uuid for dabuf buffer recovery
Rustam Kovhaev (1):
xfs: use kmem_cache_free() for kmem_cache objects
Yang Xu (1):
xfs: Fix the free logic of state in xfs_attr_node_hasname
fs/xfs/libxfs/xfs_attr.c | 17 +++++++----------
fs/xfs/xfs_aops.c | 15 ++++++++++++---
fs/xfs/xfs_buf_item_recover.c | 2 +-
fs/xfs/xfs_extfree_item.c | 6 +++---
fs/xfs/xfs_log_cil.c | 6 +++---
fs/xfs/xfs_super.c | 21 ++++++++++++++++-----
6 files changed, 42 insertions(+), 25 deletions(-)
--
2.37.0.rc0.161.g10f37bed90-goog
[resend with PATCH 5.10 prefix]
Hi Greg,
We started to experiment with the "xfs stable maintainers" concept that
Darrick has proposed.
My focus is on 5.10.y backports,
Leah's focus is on 5.15.y backports and
Chandan may pick up the 5.4.y backports.
This stable update is the first collaborated series for 5.10.y/5.15.y.
It started with a 5.15.y patch series from Leah [1] of patches that
specifically fix bugs prior to 5.10, to whom I already had tested
5.10 backport patches for.
Leah will be sending the ACKed 5.15.y series [2].
This 5.10.y series is a subset of the 5.15.y series that was
ACKed by xfs developers for 5.10.y.
All the patches in the 5.15.y series were backported to 5.10.
The ones that are not included in this 5.10.y update were more subtle
to backport, so the backports need more time for review and I will send
them in one of the following stable updates.
I would like to thank Darrick for reviewing the backport candidates.
I would like to thank Luis for his ongoing support of the kdevops [3]
test environment and Samsung for contributing the hardware to drive it.
Thanks,
Amir.
Changes since v3:
- PATCH 5.10 prefix
Changes since [v2]:
- CC stable
Changes since [v1]:
- Leave 5 out of 11
- Accked by Darrick
[1] https://lore.kernel.org/linux-xfs/20220616182749.1200971-1-leah.rumancik@gm…
[2] https://lore.kernel.org/linux-xfs/20220623203641.1710377-1-leah.rumancik@gm…
[3] https://github.com/linux-kdevops/kdevops
[v1] https://lore.kernel.org/linux-xfs/20220617100641.1653164-1-amir73il@gmail.c…
[v2] https://lore.kernel.org/linux-xfs/20220624063702.2380990-1-amir73il@gmail.c…
Brian Foster (1):
xfs: punch out data fork delalloc blocks on COW writeback failure
Darrick J. Wong (1):
xfs: remove all COW fork extents when remounting readonly
Dave Chinner (1):
xfs: check sb_meta_uuid for dabuf buffer recovery
Rustam Kovhaev (1):
xfs: use kmem_cache_free() for kmem_cache objects
Yang Xu (1):
xfs: Fix the free logic of state in xfs_attr_node_hasname
fs/xfs/libxfs/xfs_attr.c | 13 +++++--------
fs/xfs/xfs_aops.c | 15 ++++++++++++---
fs/xfs/xfs_buf_item_recover.c | 2 +-
fs/xfs/xfs_extfree_item.c | 6 +++---
fs/xfs/xfs_super.c | 14 +++++++++++---
5 files changed, 32 insertions(+), 18 deletions(-)
--
2.25.1
Den 2022-06-27 kl. 19:38, skrev Ronald Warsow:
> hallo Greg
>
> 5.18.8-rc1
>
> compiles (see [1]), boots and runs here on x86_64
> (Intel i5-11400, Fedora 36)
>
> [1]
> a regression against 5.18.7:
>
> ...
>
> LD vmlinux.o
> MODPOST vmlinux.symvers
> WARNING: modpost: vmlinux.o(___ksymtab_gpl+tick_nohz_full_setup+0x0):
> Section mismatch in reference from the variable
> __ksymtab_tick_nohz_full_setup to the function
> .init.text:tick_nohz_full_setup()
> The symbol tick_nohz_full_setup is exported and annotated __init
> Fix this by removing the __init annotation of tick_nohz_full_setup or
> drop the export.
Should be fixed by:
From 2390095113e98fc52fffe35c5206d30d9efe3f78 Mon Sep 17 00:00:00 2001
From: Masahiro Yamada <masahiroy(a)kernel.org>
Date: Mon, 27 Jun 2022 12:22:09 +0900
Subject: [PATCH] tick/nohz: unexport __init-annotated tick_nohz_full_setup()
--
Thomas
This is an attempt to direct the bots and human that are testing
LTS 5.10.y towards the maintainer of xfs in the 5.10.y tree.
This is not an upstream MAINTAINERS entry and 5.15.y and 5.4.y will
have their own LTS xfs maintainer entries.
Update Darrick's email address from upstream and add Amir as xfs
maintaier for the 5.10.y tree.
Suggested-by: Darrick J. Wong <djwong(a)kernel.org>
Link: https://lore.kernel.org/linux-xfs/Yrx6%2F0UmYyuBPjEr@magnolia/
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Reviewed-by: Darrick J. Wong <djwong(a)kernel.org>
---
Greg,
We decided to try and fork MAINTAINERS.
I don't know if this was attempted before and I don't know if you
think that is a good idea, but the rationale is that at least some
of the scripts that report bugs on LTS, will be running get_maintainer.pl
on the LTS branch they are testing.
The scripts that run get_maintainer.pl on master can be tought to
do the right thing for LTS reporting.
This seems easier and more practical then teaching the scripts to
parse LTS specific entries in upstream MAINTAINERS.
You have another patch like that coming fro Leah for 5.15.y.
Thanks,
Amir.
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7c118b507912..4d10e79030a9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19246,7 +19246,8 @@ F: arch/x86/xen/*swiotlb*
F: drivers/xen/*swiotlb*
XFS FILESYSTEM
-M: Darrick J. Wong <darrick.wong(a)oracle.com>
+M: Amir Goldstein <amir73il(a)gmail.com>
+M: Darrick J. Wong <djwong(a)kernel.org>
M: linux-xfs(a)vger.kernel.org
L: linux-xfs(a)vger.kernel.org
S: Supported
--
2.25.1