user/sven/linux.git, branch v5.15.52

Linux 5.15.52

2022-07-02T14:41:19Z

Link: https://lore.kernel.org/r/20220630133232.926711493@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Bagas Sanjaya Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Christian Brauner (Microsoft) Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman

io_uring: fix not locked access to fixed buf table

2022-07-02T14:41:18Z

commit 05b538c1765f8d14a71ccf5f85258dcbeaf189f7 upstream. We can look inside the fixed buffer table only while holding ->uring_lock, however in some cases we don't do the right async prep for IORING_OP_{WRITE,READ}_FIXED ending up with NULL req->imu forcing making an io-wq worker to try to resolve the fixed buffer without proper locking. Move req->imu setup into early req init paths, i.e. io_prep_rw(), which is called unconditionally for rw requests and under uring_lock. Fixes: 634d00df5e1cf ("io_uring: add full-fledged dynamic buffers support") Signed-off-by: Pavel Begunkov Signed-off-by: Greg Kroah-Hartman

net: mscc: ocelot: allow unregistered IP multicast flooding to CPU

2022-07-02T14:41:18Z

Since commit 4cf35a2b627a ("net: mscc: ocelot: fix broken IP multicast flooding") from v5.12, unregistered IP multicast flooding is configurable in the ocelot driver for bridged ports. However, by writing 0 to the PGID_MCIPV4 and PGID_MCIPV6 port masks at initialization time, the CPU port module, for which ocelot_port_set_mcast_flood() is not called, will have unknown IP multicast flooding disabled. This makes it impossible for an application such as smcroute to work properly, since all IP multicast traffic received on a standalone port is treated as unregistered (and dropped). Starting with commit 7569459a52c9 ("net: dsa: manage flooding on the CPU ports"), the limitation above has been lifted, because when standalone ports become IFF_PROMISC or IFF_ALLMULTI, ocelot_port_set_mcast_flood() would be called on the CPU port module, so unregistered multicast is flooded to the CPU on an as-needed basis. But between v5.12 and v5.18, IP multicast flooding to the CPU has remained broken, promiscuous or not. Delete the inexplicable premature optimization of clearing PGID_MCIPV4 and PGID_MCIPV6 as part of the init sequence, and allow unregistered IP multicast to be flooded freely to the CPU port module. Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support") Cc: stable@kernel.org Signed-off-by: Vladimir Oltean Signed-off-by: Greg Kroah-Hartman

rtw88: rtw8821c: enable rfe 6 devices

2022-07-02T14:41:18Z

commit e109e3617e5d563b431a52e6e2f07f0fc65a93ae upstream. Ping-Ke Shih answered[1] a question for a user about an rtl8821ce device that reported RFE 6, which the driver did not support. Ping-Ke suggested a possible fix, but the user never reported back. A second user discovered the above thread and tested the proposed fix. Accordingly, I am pushing this change, even though I am not the author. [1] https://lore.kernel.org/linux-wireless/3f5e2f6eac344316b5dd518ebfea2f95@realtek.com/ Signed-off-by: Ping-Ke Shih Reported-and-tested-by: masterzorag Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220107024739.20967-1-Larry.Finger@lwfinger.net Signed-off-by: Meng Tang Signed-off-by: Greg Kroah-Hartman

rtw88: 8821c: support RFE type4 wifi NIC

2022-07-02T14:41:17Z

commit b789e3fe7047296be0ccdbb7ceb0b58856053572 upstream. RFE type4 is a new NIC which has one RF antenna shares with BT. RFE type4 HW is the same as RFE type2 but attaching antenna to aux antenna connector. RFE type2 attach antenna to main antenna connector. Load the same parameter as RFE type2 when initializing NIC. Signed-off-by: Guo-Feng Fan Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210922023637.9357-1-pkshih@realtek.com Signed-off-by: Meng Tang Signed-off-by: Greg Kroah-Hartman

fs: account for group membership

2022-07-02T14:41:17Z

commit 168f912893407a5acb798a4a58613b5f1f98c717 upstream. 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 Cc: Christoph Hellwig Cc: Aleksa Sarai Cc: Al Viro Cc: stable@vger.kernel.org # 5.15+ CC: linux-fsdevel@vger.kernel.org Reviewed-by: Seth Forshee Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Greg Kroah-Hartman

fs: fix acl translation

2022-07-02T14:41:17Z

commit 705191b03d507744c7e097f78d583621c14988ac upstream. Last cycle we extended the idmapped mounts infrastructure to support idmapped mounts of idmapped filesystems (No such filesystem yet exist.). Since then, the meaning of an idmapped mount is a mount whose idmapping is different from the filesystems idmapping. While doing that work we missed to adapt the acl translation helpers. They still assume that checking for the identity mapping is enough. But they need to use the no_idmapping() helper instead. Note, POSIX ACLs are always translated right at the userspace-kernel boundary using the caller's current idmapping and the initial idmapping. The order depends on whether we're coming from or going to userspace. The filesystem's idmapping doesn't matter at the border. Consequently, if a non-idmapped mount is passed we need to make sure to always pass the initial idmapping as the mount's idmapping and not the filesystem idmapping. Since it's irrelevant here it would yield invalid ids and prevent setting acls for filesystems that are mountable in a userns and support posix acls (tmpfs and fuse). I verified the regression reported in [1] and verified that this patch fixes it. A regression test will be added to xfstests in parallel. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215849 [1] Fixes: bd303368b776 ("fs: support mapped mounts of mapped filesystems") Cc: Seth Forshee Cc: Christoph Hellwig Cc: # 5.15+ Cc: Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Linus Torvalds Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Greg Kroah-Hartman

fs: support mapped mounts of mapped filesystems

2022-07-02T14:41:17Z

commit bd303368b776eead1c29e6cdda82bde7128b82a7 upstream. In previous patches we added new and modified existing helpers to handle idmapped mounts of filesystems mounted with an idmapping. In this final patch we convert all relevant places in the vfs to actually pass the filesystem's idmapping into these helpers. With this the vfs is in shape to handle idmapped mounts of filesystems mounted with an idmapping. Note that this is just the generic infrastructure. Actually adding support for idmapped mounts to a filesystem mountable with an idmapping is follow-up work. In this patch we extend the definition of an idmapped mount from a mount that that has the initial idmapping attached to it to a mount that has an idmapping attached to it which is not the same as the idmapping the filesystem was mounted with. As before we do not allow the initial idmapping to be attached to a mount. In addition this patch prevents that the idmapping the filesystem was mounted with can be attached to a mount created based on this filesystem. This has multiple reasons and advantages. First, attaching the initial idmapping or the filesystem's idmapping doesn't make much sense as in both cases the values of the i_{g,u}id and other places where k{g,u}ids are used do not change. Second, a user that really wants to do this for whatever reason can just create a separate dedicated identical idmapping to attach to the mount. Third, we can continue to use the initial idmapping as an indicator that a mount is not idmapped allowing us to continue to keep passing the initial idmapping into the mapping helpers to tell them that something isn't an idmapped mount even if the filesystem is mounted with an idmapping. Link: https://lore.kernel.org/r/20211123114227.3124056-11-brauner@kernel.org (v1) Link: https://lore.kernel.org/r/20211130121032.3753852-11-brauner@kernel.org (v2) Link: https://lore.kernel.org/r/20211203111707.3901969-11-brauner@kernel.org Cc: Seth Forshee Cc: Amir Goldstein Cc: Christoph Hellwig Cc: Al Viro CC: linux-fsdevel@vger.kernel.org Reviewed-by: Seth Forshee Signed-off-by: Christian Brauner Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Greg Kroah-Hartman

fs: add i_user_ns() helper

2022-07-02T14:41:16Z

commit a1ec9040a2a9122605ac26e5725c6de019184419 upstream. Since we'll be passing the filesystem's idmapping in even more places in the following patches and we do already dereference struct inode to get to the filesystem's idmapping multiple times add a tiny helper. Link: https://lore.kernel.org/r/20211123114227.3124056-10-brauner@kernel.org (v1) Link: https://lore.kernel.org/r/20211130121032.3753852-10-brauner@kernel.org (v2) Link: https://lore.kernel.org/r/20211203111707.3901969-10-brauner@kernel.org Cc: Seth Forshee Cc: Christoph Hellwig Cc: Al Viro CC: linux-fsdevel@vger.kernel.org Reviewed-by: Amir Goldstein Reviewed-by: Seth Forshee Signed-off-by: Christian Brauner Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Greg Kroah-Hartman

fs: port higher-level mapping helpers

2022-07-02T14:41:16Z

commit 209188ce75d0d357c292f6bb81d712acdd4e7db7 upstream. Enable the mapped_fs{g,u}id() helpers to support filesystems mounted with an idmapping. Apart from core mapping helpers that use mapped_fs{g,u}id() to initialize struct inode's i_{g,u}id fields xfs is the only place that uses these low-level helpers directly. The patch only extends the helpers to be able to take the filesystem idmapping into account. Since we don't actually yet pass the filesystem's idmapping in no functional changes happen. This will happen in a final patch. Link: https://lore.kernel.org/r/20211123114227.3124056-9-brauner@kernel.org (v1) Link: https://lore.kernel.org/r/20211130121032.3753852-9-brauner@kernel.org (v2) Link: https://lore.kernel.org/r/20211203111707.3901969-9-brauner@kernel.org Cc: Seth Forshee Cc: Christoph Hellwig Cc: Al Viro CC: linux-fsdevel@vger.kernel.org Reviewed-by: Amir Goldstein Reviewed-by: Seth Forshee Signed-off-by: Christian Brauner Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Greg Kroah-Hartman