commit e07f317d5a289f06b7eb9025d2ada744cf22c940 Author: Greg Kroah-Hartman Date: Wed Sep 8 08:49:02 2021 +0200 Linux 5.10.63 Link: https://lore.kernel.org/r/20210906125449.756437409@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Fox Chen Tested-by: Linux Kernel Functional Testing Tested-by: Hulk Robot Tested-by: Sudip Mukherjee Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Salvatore Bonaccorso commit 4405ea221deaf7c5b4b5d40f8186e9574ea43196 Author: Pavel Skripkin Date: Wed Jul 7 19:54:30 2021 +0200 media: stkwebcam: fix memory leak in stk_camera_probe commit 514e97674400462cc09c459a1ddfb9bf39017223 upstream. My local syzbot instance hit memory leak in usb_set_configuration(). The problem was in unputted usb interface. In case of errors after usb_get_intf() the reference should be putted to correclty free memory allocated for this interface. Fixes: ec16dae5453e ("V4L/DVB (7019): V4L: add support for Syntek DC1125 webcams") Cc: stable@vger.kernel.org Signed-off-by: Pavel Skripkin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit ad5e13f15db76844365a959a6e4c79ae5f48129c Author: Amir Goldstein Date: Mon Jun 21 14:03:53 2021 +0300 fuse: fix illegal access to inode with reused nodeid commit 15db16837a35d8007cb8563358787412213db25e upstream. Server responds to LOOKUP and other ops (READDIRPLUS/CREATE/MKNOD/...) with ourarg containing nodeid and generation. If a fuse inode is found in inode cache with the same nodeid but different generation, the existing fuse inode should be unhashed and marked "bad" and a new inode with the new generation should be hashed instead. This can happen, for example, with passhrough fuse filesystem that returns the real filesystem ino/generation on lookup and where real inode numbers can get recycled due to real files being unlinked not via the fuse passthrough filesystem. With current code, this situation will not be detected and an old fuse dentry that used to point to an older generation real inode, can be used to access a completely new inode, which should be accessed only via the new dentry. Note that because the FORGET message carries the nodeid w/o generation, the server should wait to get FORGET counts for the nlookup counts of the old and reused inodes combined, before it can free the resources associated to that nodeid. Stable backport notes: * This is not a regression. The bug has been in fuse forever, but only a certain class of low level fuse filesystems can trigger this bug * Because there is no way to check if this fix is applied in runtime, libfuse test_examples.py tests this fix with hardcoded check for kernel version >= 5.14 * After backport to stable kernel(s), the libfuse test can be updated to also check minimal stable kernel version(s) * Depends on "fuse: fix bad inode" which is already applied to stable kernels v5.4.y and v5.10.y * Required backporting helper inode_wrong_type() Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-fsdevel/CAOQ4uxi8DymG=JO_sAU+wS8akFdzh+PuXwW3Ebgahd2Nwnh7zA@mail.gmail.com/ Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 40ba433a85dbbf5b2e58f2ac6b161ce37ac872fc Author: Al Viro Date: Mon Mar 1 20:37:10 2021 -0500 new helper: inode_wrong_type() commit 6e3e2c4362e41a2f18e3f7a5ad81bd2f49a47b85 upstream. inode_wrong_type(inode, mode) returns true if setting inode->i_mode to given value would've changed the inode type. We have enough of those checks open-coded to make a helper worthwhile. Signed-off-by: Al Viro Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit ded9137fcf0d729dbe65aa98c411352f40b22970 Author: Andy Shevchenko Date: Mon May 10 16:12:42 2021 +0300 spi: Switch to signed types for *_native_cs SPI controller fields commit 35f3f8504c3b60a1ae5576e178b27fc0ddd6157d upstream. While fixing undefined behaviour the commit f60d7270c8a3 ("spi: Avoid undefined behaviour when counting unused native CSs") missed the case when all CSs are GPIOs and thus unused_native_cs will be evaluated to -1 in unsigned representation. This will falsely trigger a condition in the spi_get_gpio_descs(). Switch to signed types for *_native_cs SPI controller fields to fix above. Fixes: f60d7270c8a3 ("spi: Avoid undefined behaviour when counting unused native CSs") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210510131242.49455-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Nobuhiro Iwamatsu (CIP) Signed-off-by: Greg Kroah-Hartman commit 55bb5193cec58f8ffb73df6b8feb0d4b0ada53f4 Author: Vignesh Raghavendra Date: Wed Nov 11 16:56:52 2020 +0530 serial: 8250: 8250_omap: Fix possible array out of bounds access commit d4548b14dd7e5c698f81ce23ce7b69a896373b45 upstream. k3_soc_devices array is missing a sentinel entry which may result in out of bounds access as reported by kernel KASAN. Fix this by adding a sentinel entry. Fixes: 439c7183e5b9 ("serial: 8250: 8250_omap: Disable RX interrupt after DMA enable") Reported-by: Naresh Kamboju Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20201111112653.2710-1-vigneshr@ti.com Signed-off-by: Nobuhiro Iwamatsu (CIP) Signed-off-by: Greg Kroah-Hartman commit 8e41134a92a50a11ecf7823bc1a19a4dd347463a Author: Zubin Mithra Date: Fri Aug 27 08:37:35 2021 -0700 ALSA: pcm: fix divide error in snd_pcm_lib_ioctl commit f3eef46f0518a2b32ca1244015820c35a22cfe4a upstream. Syzkaller reported a divide error in snd_pcm_lib_ioctl. fifo_size is of type snd_pcm_uframes_t(unsigned long). If frame_size is 0x100000000, the error occurs. Fixes: a9960e6a293e ("ALSA: pcm: fix fifo_size frame calculation") Signed-off-by: Zubin Mithra Reviewed-by: Guenter Roeck Cc: Link: https://lore.kernel.org/r/20210827153735.789452-1-zsm@chromium.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4ffde17862b0565b351707ecc2586705a17e557d Author: Takashi Iwai Date: Fri Aug 20 16:32:14 2021 +0200 ALSA: hda/realtek: Workaround for conflicting SSID on ASUS ROG Strix G17 commit 13d9c6b998aaa76fd098133277a28a21f2cc2264 upstream. ASUS ROG Strix G17 has the very same PCI and codec SSID (1043:103f) as ASUS TX300, and unfortunately, the existing quirk for TX300 is broken on ASUS ROG. Actually the device works without the quirk, so we'll need to clear the quirk before applying for this device. Since ASUS ROG has a different codec (ALC294 - while TX300 has ALC282), this patch adds a workaround for the device, just clearing the codec->fixup_id by checking the codec vendor_id. It's a bit ugly to add such a workaround there, but it seems to be the simplest way. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214101 Cc: Link: https://lore.kernel.org/r/20210820143214.3654-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4ee2686b3745ea9b003431e2c036a5ccfbb434e2 Author: Johnathon Clark Date: Mon Aug 23 17:21:10 2021 +0100 ALSA: hda/realtek: Quirk for HP Spectre x360 14 amp setup commit 93ab3eafb0b3551c54175cb38afed3b82356a047 upstream. This patch extends support for the HP Spectre x360 14 amp enable quirk to support a model of the device with an additional subdevice ID. Signed-off-by: Johnathon Clark Link: https://lore.kernel.org/r/20210823162110.8870-1-john.clark@cantab.net Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2808d59fb29b5226fa8475b0e33fb9a031bc9638 Author: Christoph Hellwig Date: Fri Aug 27 18:32:50 2021 +0200 cryptoloop: add a deprecation warning [ Upstream commit 222013f9ac30b9cec44301daa8dbd0aae38abffb ] Support for cryptoloop has been officially marked broken and deprecated in favor of dm-crypt (which supports the same broken algorithms if needed) in Linux 2.6.4 (released in March 2004), and support for it has been entirely removed from losetup in util-linux 2.23 (released in April 2013). Add a warning and a deprecation schedule. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20210827163250.255325-1-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 61a038f80c8082e6e867525206c06612997b9d91 Author: Kim Phillips Date: Tue Aug 17 17:10:43 2021 -0500 perf/x86/amd/power: Assign pmu.module [ Upstream commit ccf26483416a339c114409f6e7cd02abdeaf8052 ] Assign pmu.module so the driver can't be unloaded whilst in use. Signed-off-by: Kim Phillips Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210817221048.88063-4-kim.phillips@amd.com Signed-off-by: Sasha Levin commit ec9a82e034f65393999effe206ffb56f2d74f2b4 Author: Kim Phillips Date: Tue Aug 17 17:10:42 2021 -0500 perf/x86/amd/ibs: Work around erratum #1197 [ Upstream commit 26db2e0c51fe83e1dd852c1321407835b481806e ] Erratum #1197 "IBS (Instruction Based Sampling) Register State May be Incorrect After Restore From CC6" is published in a document: "Revision Guide for AMD Family 19h Models 00h-0Fh Processors" 56683 Rev. 1.04 July 2021 https://bugzilla.kernel.org/show_bug.cgi?id=206537 Implement the erratum's suggested workaround and ignore IBS samples if MSRC001_1031 == 0. Signed-off-by: Kim Phillips Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210817221048.88063-3-kim.phillips@amd.com Signed-off-by: Sasha Levin commit 23c29490b84dd89582b7d3233e97f73c41f1a065 Author: Tuo Li Date: Thu Aug 5 08:14:34 2021 -0700 ceph: fix possible null-pointer dereference in ceph_mdsmap_decode() [ Upstream commit a9e6ffbc5b7324b6639ee89028908b1e91ceed51 ] kcalloc() is called to allocate memory for m->m_info, and if it fails, ceph_mdsmap_destroy() behind the label out_err will be called: ceph_mdsmap_destroy(m); In ceph_mdsmap_destroy(), m->m_info is dereferenced through: kfree(m->m_info[i].export_targets); To fix this possible null-pointer dereference, check m->m_info before the for loop to free m->m_info[i].export_targets. [ jlayton: fix up whitespace damage only kfree(m->m_info) if it's non-NULL ] Reported-by: TOTE Robot Signed-off-by: Tuo Li Signed-off-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit d2064a1444d67875c2b4ff1ee5dd55d7abee6bff Author: Xiaoyao Li Date: Tue Aug 24 12:06:22 2021 +0800 perf/x86/intel/pt: Fix mask of num_address_ranges [ Upstream commit c53c6b7409f4cd9e542991b53d597fbe2751d7db ] Per SDM, bit 2:0 of CPUID(0x14,1).EAX[2:0] reports the number of configurable address ranges for filtering, not bit 1:0. Signed-off-by: Xiaoyao Li Signed-off-by: Peter Zijlstra (Intel) Acked-by: Alexander Shishkin Link: https://lkml.kernel.org/r/20210824040622.4081502-1-xiaoyao.li@intel.com Signed-off-by: Sasha Levin commit 0e74bba60452150016864095b4896cd6d6cd2af9 Author: Shai Malin Date: Tue Aug 24 19:52:49 2021 +0300 qede: Fix memset corruption [ Upstream commit e543468869e2532f5d7926e8f417782b48eca3dc ] Thanks to Kees Cook who detected the problem of memset that starting from not the first member, but sized for the whole struct. The better change will be to remove the redundant memset and to clear only the msix_cnt member. Signed-off-by: Prabhakar Kushwaha Signed-off-by: Ariel Elior Signed-off-by: Shai Malin Reported-by: Kees Cook Reviewed-by: Kees Cook Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 35f223cb21b1cb75175e736cb5b1b2615ae6d342 Author: Harini Katakam Date: Tue Aug 24 15:32:09 2021 +0530 net: macb: Add a NULL check on desc_ptp [ Upstream commit 85520079afce885b80647fbd0d13d8f03d057167 ] macb_ptp_desc will not return NULL under most circumstances with correct Kconfig and IP design config register. But for the sake of the extreme corner case, check for NULL when using the helper. In case of rx_tstamp, no action is necessary except to return (similar to timestamp disabled) and warn. In case of TX, return -EINVAL to let the skb be free. Perform this check before marking skb in progress. Fixes coverity warning: (4) Event dereference: Dereferencing a null pointer "desc_ptp" Signed-off-by: Harini Katakam Reviewed-by: Radhey Shyam Pandey Signed-off-by: Michal Simek Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cf50d02e474be9f0d6f2fed9aecf4dc90cc6e729 Author: Shai Malin Date: Sun Aug 22 22:21:14 2021 +0300 qed: Fix the VF msix vectors flow [ Upstream commit b0cd08537db8d2fbb227cdb2e5835209db295a24 ] For VFs we should return with an error in case we didn't get the exact number of msix vectors as we requested. Not doing that will lead to a crash when starting queues for this VF. Signed-off-by: Prabhakar Kushwaha Signed-off-by: Ariel Elior Signed-off-by: Shai Malin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2177c4943e40e6f04a78e506faaacda0384e3e89 Author: Sai Krishna Potthuri Date: Wed Jun 23 13:46:20 2021 +0200 reset: reset-zynqmp: Fixed the argument data type [ Upstream commit ed104ca4bd9c405b41e968ad4ece51f6462e90b6 ] This patch changes the data type of the variable 'val' from int to u32. Addresses-Coverity: argument of type "int *" is incompatible with parameter of type "u32 *" Signed-off-by: Sai Krishna Potthuri Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/925cebbe4eb73c7d0a536da204748d33c7100d8c.1624448778.git.michal.simek@xilinx.com Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit 9872349b088d5a94ccbe23c2ded8820b5a082cea Author: Krzysztof Hałasa Date: Mon Jun 7 12:49:07 2021 +0200 gpu: ipu-v3: Fix i.MX IPU-v3 offset calculations for (semi)planar U/V formats [ Upstream commit 7cca7c8096e2c8a4149405438329b5035d0744f0 ] Video captured in 1400x1050 resolution (bytesperline aka stride = 1408 bytes) is invalid. Fix it. Signed-off-by: Krzysztof Halasa Link: https://lore.kernel.org/r/m3y2bmq7a4.fsf@t19.piap.pl [p.zabel@pengutronix.de: added "gpu: ipu-v3:" prefix to commit description] Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit b983d60292a610b21c15d3c38c6031880e58e750 Author: Maciej Falkowski Date: Thu Apr 1 18:04:34 2021 +0200 ARM: OMAP1: ams-delta: remove unused function ams_delta_camera_power commit bae989c4bc53f861cc1b706aab0194703e9907a8 upstream. The ams_delta_camera_power() function is unused as reports Clang compilation with omap1_defconfig on linux-next: arch/arm/mach-omap1/board-ams-delta.c:462:12: warning: unused function 'ams_delta_camera_power' [-Wunused-function] static int ams_delta_camera_power(struct device *dev, int power) ^ 1 warning generated. The soc_camera support was dropped without removing ams_delta_camera_power() function, making it unused. Fixes: ce548396a433 ("media: mach-omap1: board-ams-delta.c: remove soc_camera dependencies") Signed-off-by: Maciej Falkowski Reviewed-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Tony Lindgren Link: https://github.com/ClangBuiltLinux/linux/issues/1326 Signed-off-by: Greg Kroah-Hartman commit bc860c3f09453cbd8680b133ff6434cdb1f4ca9e Author: Randy Dunlap Date: Wed May 26 00:03:37 2021 -0700 xtensa: fix kconfig unmet dependency warning for HAVE_FUTEX_CMPXCHG commit ed5aacc81cd41efc4d561e14af408d1003f7b855 upstream. XTENSA should only select HAVE_FUTEX_CMPXCHG when FUTEX is set/enabled. This prevents a kconfig warning. WARNING: unmet direct dependencies detected for HAVE_FUTEX_CMPXCHG Depends on [n]: FUTEX [=n] Selected by [y]: - XTENSA [=y] && !MMU [=n] Fixes: d951ba21b959 ("xtensa: nommu: select HAVE_FUTEX_CMPXCHG") Signed-off-by: Randy Dunlap Cc: Max Filippov Cc: Chris Zankel Cc: linux-xtensa@linux-xtensa.org Message-Id: <20210526070337.28130-1-rdunlap@infradead.org> Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit b1075d2a705266a9051857810e0d2ac55a9e232f Author: Matthieu Baerts Date: Fri Mar 26 11:50:23 2021 +0100 static_call: Fix unused variable warn w/o MODULE commit 7d95f22798ecea513f37b792b39fec4bcf20fec3 upstream. Here is the warning converted as error and reported by GCC: kernel/static_call.c: In function ‘__static_call_update’: kernel/static_call.c:153:18: error: unused variable ‘mod’ [-Werror=unused-variable] 153 | struct module *mod = site_mod->mod; | ^~~ cc1: all warnings being treated as errors make[1]: *** [scripts/Makefile.build:271: kernel/static_call.o] Error 1 This is simply because since recently, we no longer use 'mod' variable elsewhere if MODULE is unset. When using 'make tinyconfig' to generate the default kconfig, MODULE is unset. There are different ways to fix this warning. Here I tried to minimised the number of modified lines and not add more #ifdef. We could also move the declaration of the 'mod' variable inside the if-statement or directly use site_mod->mod. Fixes: 698bacefe993 ("static_call: Align static_call_is_init() patching condition") Signed-off-by: Matthieu Baerts Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210326105023.2058860-1-matthieu.baerts@tessares.net Signed-off-by: Greg Kroah-Hartman commit ae16b7c668378ea00eb60ab9d29e0d46b0e7aa15 Author: Greg Kroah-Hartman Date: Fri Sep 3 16:06:50 2021 +0200 Revert "Add a reference to ucounts for each cred" This reverts commit b2c4d9a33cc2dec7466f97eba2c4dd571ad798a5 which is commit 905ae01c4ae2ae3df05bb141801b1db4b7d83c61 upstream. This commit should not have been applied to the 5.10.y stable tree, so revert it. Reported-by: "Eric W. Biederman" Link: https://lore.kernel.org/r/87v93k4bl6.fsf@disp2133 Cc: Alexey Gladkov Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1aa3f27e592dea3b6cbc5ef5ec979ba5f511d410 Author: Greg Kroah-Hartman Date: Fri Sep 3 16:06:40 2021 +0200 Revert "cred: add missing return error code when set_cred_ucounts() failed" This reverts commit 0855952ed4f1a6861fbb0e5d684efd447d7347c9 which is commit 5e6b8a50a7cec5686ee2c4bda1d49899c79a7eae upstream. The "original" commit 905ae01c4ae2 ("Add a reference to ucounts for each cred"), should not have been applied to the 5.10.y tree, so revert it, and the follow-on fixup patches as well. Reported-by: "Eric W. Biederman" Link: https://lore.kernel.org/r/87v93k4bl6.fsf@disp2133 Cc: Yang Yingliang Cc: Alexey Gladkov Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0c1443874e1cb359b377a0e383c0dcce81aefa12 Author: Greg Kroah-Hartman Date: Fri Sep 3 16:06:21 2021 +0200 Revert "ucounts: Increase ucounts reference counter before the security hook" This reverts commit b493af3a66e067f93e5e03465507866ddeabff9e which is commit bbb6d0f3e1feb43d663af089c7dedb23be6a04fb upstream. The "original" commit 905ae01c4ae2 ("Add a reference to ucounts for each cred"), should not have been applied to the 5.10.y tree, so revert it, and the follow-on fixup patches as well. Reported-by: "Eric W. Biederman" Link: https://lore.kernel.org/r/87v93k4bl6.fsf@disp2133 Cc: Alexey Gladkov Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0479b2bd2959ae03e7f727a797ea87b3d0b7dfb2 Author: Eric Biggers Date: Wed Sep 1 09:27:21 2021 -0700 ubifs: report correct st_size for encrypted symlinks commit 064c734986011390b4d111f1a99372b7f26c3850 upstream. The stat() family of syscalls report the wrong size for encrypted symlinks, which has caused breakage in several userspace programs. Fix this by calling fscrypt_symlink_getattr() after ubifs_getattr() for encrypted symlinks. This function computes the correct size by reading and decrypting the symlink target (if it's not already cached). For more details, see the commit which added fscrypt_symlink_getattr(). Fixes: ca7f85be8d6c ("ubifs: Add support for encrypted symlinks") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210702065350.209646-5-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 3ac01789f6d9ca93ecc1faecd23414c13b4582c9 Author: Eric Biggers Date: Wed Sep 1 09:27:20 2021 -0700 f2fs: report correct st_size for encrypted symlinks commit 461b43a8f92e68e96c4424b31e15f2b35f1bbfa9 upstream. The stat() family of syscalls report the wrong size for encrypted symlinks, which has caused breakage in several userspace programs. Fix this by calling fscrypt_symlink_getattr() after f2fs_getattr() for encrypted symlinks. This function computes the correct size by reading and decrypting the symlink target (if it's not already cached). For more details, see the commit which added fscrypt_symlink_getattr(). Fixes: cbaf042a3cc6 ("f2fs crypto: add symlink encryption") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210702065350.209646-4-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 894a02236d0d20305556af4bfba3259f28c0b86b Author: Eric Biggers Date: Wed Sep 1 09:27:19 2021 -0700 ext4: report correct st_size for encrypted symlinks commit 8c4bca10ceafc43b1ca0a9fab5fa27e13cbce99e upstream. The stat() family of syscalls report the wrong size for encrypted symlinks, which has caused breakage in several userspace programs. Fix this by calling fscrypt_symlink_getattr() after ext4_getattr() for encrypted symlinks. This function computes the correct size by reading and decrypting the symlink target (if it's not already cached). For more details, see the commit which added fscrypt_symlink_getattr(). Fixes: f348c252320b ("ext4 crypto: add symlink encryption") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210702065350.209646-3-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit b8c298cf57dcb5b18855f11437199fd0eb1ea388 Author: Eric Biggers Date: Wed Sep 1 09:27:18 2021 -0700 fscrypt: add fscrypt_symlink_getattr() for computing st_size commit d18760560593e5af921f51a8c9b64b6109d634c2 upstream. Add a helper function fscrypt_symlink_getattr() which will be called from the various filesystems' ->getattr() methods to read and decrypt the target of encrypted symlinks in order to report the correct st_size. Detailed explanation: As required by POSIX and as documented in various man pages, st_size for a symlink is supposed to be the length of the symlink target. Unfortunately, st_size has always been wrong for encrypted symlinks because st_size is populated from i_size from disk, which intentionally contains the length of the encrypted symlink target. That's slightly greater than the length of the decrypted symlink target (which is the symlink target that userspace usually sees), and usually won't match the length of the no-key encoded symlink target either. This hadn't been fixed yet because reporting the correct st_size would require reading the symlink target from disk and decrypting or encoding it, which historically has been considered too heavyweight to do in ->getattr(). Also historically, the wrong st_size had only broken a test (LTP lstat03) and there were no known complaints from real users. (This is probably because the st_size of symlinks isn't used too often, and when it is, typically it's for a hint for what buffer size to pass to readlink() -- which a slightly-too-large size still works for.) However, a couple things have changed now. First, there have recently been complaints about the current behavior from real users: - Breakage in rpmbuild: https://github.com/rpm-software-management/rpm/issues/1682 https://github.com/google/fscrypt/issues/305 - Breakage in toybox cpio: https://www.mail-archive.com/toybox@lists.landley.net/msg07193.html - Breakage in libgit2: https://issuetracker.google.com/issues/189629152 (on Android public issue tracker, requires login) Second, we now cache decrypted symlink targets in ->i_link. Therefore, taking the performance hit of reading and decrypting the symlink target in ->getattr() wouldn't be as big a deal as it used to be, since usually it will just save having to do the same thing later. Also note that eCryptfs ended up having to read and decrypt symlink targets in ->getattr() as well, to fix this same issue; see commit 3a60a1686f0d ("eCryptfs: Decrypt symlink target for stat size"). So, let's just bite the bullet, and read and decrypt the symlink target in ->getattr() in order to report the correct st_size. Add a function fscrypt_symlink_getattr() which the filesystems will call to do this. (Alternatively, we could store the decrypted size of symlinks on-disk. But there isn't a great place to do so, and encryption is meant to hide the original size to some extent; that property would be lost.) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210702065350.209646-2-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 09a379549620f122de3aa4e65df9329976e4cdf5 Author: Theodore Ts'o Date: Fri Aug 20 23:44:17 2021 -0400 ext4: fix race writing to an inline_data file while its xattrs are changing commit a54c4613dac1500b40e4ab55199f7c51f028e848 upstream. The location of the system.data extended attribute can change whenever xattr_sem is not taken. So we need to recalculate the i_inline_off field since it mgiht have changed between ext4_write_begin() and ext4_write_end(). This means that caching i_inline_off is probably not helpful, so in the long run we should probably get rid of it and shrink the in-memory ext4 inode slightly, but let's fix the race the simple way for now. Cc: stable@kernel.org Fixes: f19d5870cbf72 ("ext4: add normal write support for inline data") Reported-by: syzbot+13146364637c7363a7de@syzkaller.appspotmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman