kernel/linux.git, branch v6.6.44

Linux 6.6.44

2024-08-03T06:54:42+00:00

Link: https://lore.kernel.org/r/20240730151639.792277039@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Mark Brown Tested-by: Linux Kernel Functional Testing Tested-by: Takeshi Ogasawara Tested-by: Jon Hunter Tested-by: Peter Schneider Tested-by: Allen Pais Tested-by: SeongJae Park Tested-by: Ron Economos Tested-by: kernelci.org bot Tested-by: Conor Dooley Signed-off-by: Greg Kroah-Hartman

fs: don't allow non-init s_user_ns for filesystems without FS_USERNS_MOUNT

2024-08-03T06:54:41+00:00

[ Upstream commit e1c5ae59c0f22f7fe5c07fb5513a29e4aad868c9 ] Christian noticed that it is possible for a privileged user to mount most filesystems with a non-initial user namespace in sb->s_user_ns. When fsopen() is called in a non-init namespace the caller's namespace is recorded in fs_context->user_ns. If the returned file descriptor is then passed to a process priviliged in init_user_ns, that process can call fsconfig(fd_fs, FSCONFIG_CMD_CREATE), creating a new superblock with sb->s_user_ns set to the namespace of the process which called fsopen(). This is problematic. We cannot assume that any filesystem which does not set FS_USERNS_MOUNT has been written with a non-initial s_user_ns in mind, increasing the risk for bugs and security issues. Prevent this by returning EPERM from sget_fc() when FS_USERNS_MOUNT is not set for the filesystem and a non-initial user namespace will be used. sget() does not need to be updated as it always uses the user namespace of the current context, or the initial user namespace if SB_SUBMOUNT is set. Fixes: cb50b348c71f ("convenience helpers: vfs_get_super() and sget_fc()") Reported-by: Christian Brauner Signed-off-by: Seth Forshee (DigitalOcean) Link: https://lore.kernel.org/r/20240724-s_user_ns-fix-v1-1-895d07c94701@kernel.org Reviewed-by: Alexander Mikhalitsyn Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin

nvme-pci: add missing condition check for existence of mapped data

2024-08-03T06:54:41+00:00

[ Upstream commit c31fad1470389666ac7169fe43aa65bf5b7e2cfd ] nvme_map_data() is called when request has physical segments, hence the nvme_unmap_data() should have same condition to avoid dereference. Fixes: 4aedb705437f ("nvme-pci: split metadata handling from nvme_map_data / nvme_unmap_data") Signed-off-by: Leon Romanovsky Reviewed-by: Christoph Hellwig Reviewed-by: Nitesh Shetty Signed-off-by: Keith Busch Signed-off-by: Sasha Levin

io_uring: fix io_match_task must_hold

2024-08-03T06:54:41+00:00

[ Upstream commit e142e9cd8891b0c6f277ac2c2c254199a6aa56e3 ] The __must_hold annotation in io_match_task() uses a non existing parameter "req", fix it. Fixes: 6af3f48bf6156 ("io_uring: fix link traversal locking") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/3e65ee7709e96507cef3d93291746f2c489f2307.1721819383.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin

iommu: sprd: Avoid NULL deref in sprd_iommu_hw_en

2024-08-03T06:54:41+00:00

[ Upstream commit 630482ee0653decf9e2482ac6181897eb6cde5b8 ] In sprd_iommu_cleanup() before calling function sprd_iommu_hw_en() dom->sdev is equal to NULL, which leads to null dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 9afea57384d4 ("iommu/sprd: Release dma buffer to avoid memory leak") Signed-off-by: Artem Chernyshev Reviewed-by: Chunyan Zhang Link: https://lore.kernel.org/r/20240716125522.3690358-1-artem.chernyshev@red-soft.ru Signed-off-by: Will Deacon Signed-off-by: Sasha Levin

s390/cpum_cf: Fix endless loop in CF_DIAG event stop

2024-08-03T06:54:41+00:00

[ Upstream commit e6ce1f12d777f6ee22b20e10ae6a771e7e6f44f5 ] Event CF_DIAG reads out complete counter sets using stcctm instruction. This is done at event start time when the process starts execution and at event stop time when the process is removed from the CPU. During removal the difference of each counter in the counter sets is calculated and saved as raw data in the ring buffer. This works fine unless the number of counters in a counter set is zero. This may happen for the extended counter set. This set is machine specific and the size of the counter set can be zero even when extended counter set is authorized for read access. This case is not handled. cfdiag_diffctr() checks authorization of the extended counter set. If true the functions assumes the extended counter set has been saved in a data buffer. However this is not the case, cfdiag_getctrset() does not save a counter set with counter set size of zero. This mismatch causes an endless loop in the counter set readout during event stop handling. The calculation of the difference of the counters in each counter now verifies the size of the counter set is non-zero. A counter set with size zero is skipped. Fixes: a029a4eab39e ("s390/cpumf: Allow concurrent access for CPU Measurement Counter Facility") Signed-off-by: Thomas Richter Acked-by: Sumanth Korikkar Acked-by: Heiko Carstens Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Alexander Gordeev Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin

s390/pci: Allow allocation of more than 1 MSI interrupt

2024-08-03T06:54:41+00:00

[ Upstream commit ab42fcb511fd9d241bbab7cc3ca04e34e9fc0666 ] On a PCI adapter that provides up to 8 MSI interrupt sources the s390 implementation of PCI interrupts rejected to accommodate them, although the underlying hardware is able to support that. For MSI-X it is sufficient to allocate a single irq_desc per msi_desc, but for MSI multiple irq descriptors are attached to and controlled by a single msi descriptor. Add the appropriate loops to maintain multiple irq descriptors and tie/untie them to/from the appropriate AIBV bit, if a device driver allocates more than 1 MSI interrupt. Common PCI code passes on requests to allocate a number of interrupt vectors based on the device drivers' demand and the PCI functions' capabilities. However, the root-complex of s390 systems support just a limited number of interrupt vectors per PCI function. Produce a kernel log message to inform about any architecture-specific capping that might be done. With this change, we had a PCI adapter successfully raising interrupts to its device driver via all 8 sources. Fixes: a384c8924a8b ("s390/PCI: Fix single MSI only check") Signed-off-by: Gerd Bayer Reviewed-by: Niklas Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin

s390/pci: Refactor arch_setup_msi_irqs()

2024-08-03T06:54:41+00:00

[ Upstream commit 5fd11b96b43708f2f6e3964412c301c1bd20ec0f ] Factor out adapter interrupt allocation from arch_setup_msi_irqs() in preparation for enabling registration of multiple MSIs. Code movement only, no change of functionality intended. Signed-off-by: Gerd Bayer Reviewed-by: Niklas Schnelle Signed-off-by: Vasily Gorbik Stable-dep-of: ab42fcb511fd ("s390/pci: Allow allocation of more than 1 MSI interrupt") Signed-off-by: Sasha Levin

ceph: fix incorrect kmalloc size of pagevec mempool

2024-08-03T06:54:40+00:00

[ Upstream commit 03230edb0bd831662a7c08b6fef66b2a9a817774 ] The kmalloc size of pagevec mempool is incorrectly calculated. It misses the size of page pointer and only accounts the number for the array. Fixes: a0102bda5bc0 ("ceph: move sb->wb_pagevec_pool to be a global mempool") Signed-off-by: ethanwu Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin

ASoC: TAS2781: Fix tasdev_load_calibrated_data()

2024-08-03T06:54:40+00:00

[ Upstream commit 92c78222168e9035a9bfb8841c2e56ce23e51f73 ] This function has a reversed if statement so it's either a no-op or it leads to a NULL dereference. Fixes: b195acf5266d ("ASoC: tas2781: Fix wrong loading calibrated data sequence") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/18a29b68-cc85-4139-b7c7-2514e8409a42@stanley.mountain Signed-off-by: Mark Brown Signed-off-by: Sasha Levin