kernel/linux.git, branch v4.19.243

Linux 4.19.243

2022-05-15T17:41:59+00:00

Link: https://lore.kernel.org/r/20220513142227.897535454@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Hulk Robot Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman

VFS: Fix memory leak caused by concurrently mounting fs with subtype

2022-05-15T17:41:59+00:00

If two processes mount same superblock, memory leak occurs: CPU0 | CPU1 do_new_mount | do_new_mount fs_set_subtype | fs_set_subtype kstrdup | | kstrdup memrory leak | The following reproducer triggers the problem: 1. shell command: mount -t ntfs /dev/sda1 /mnt & 2. c program: mount("/dev/sda1", "/mnt", "fuseblk", 0, "...") with kmemleak report being along the lines of unreferenced object 0xffff888235f1a5c0 (size 8): comm "mount.ntfs", pid 2860, jiffies 4295757824 (age 43.423s) hex dump (first 8 bytes): 00 a5 f1 35 82 88 ff ff ...5.... backtrace: [<00000000656e30cc>] __kmalloc_track_caller+0x16e/0x430 [<000000008e591727>] kstrdup+0x3e/0x90 [<000000008430d12b>] do_mount.cold+0x7b/0xd9 [<0000000078d639cd>] ksys_mount+0xb2/0x150 [<000000006015988d>] __x64_sys_mount+0x29/0x40 [<00000000e0a7c118>] do_syscall_64+0xc1/0x1d0 [<00000000bcea7df5>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [<00000000803a4067>] 0xffffffffffffffff Linus's tree already have refactoring patchset [1], one of them can fix this bug: c30da2e981a7 ("fuse: convert to use the new mount API") After refactoring, init super_block->s_subtype in fuse_fill_super. Since we did not merge the refactoring patchset in this branch, I create this patch. This patch fix this by adding a write lock while calling fs_set_subtype. [1] https://patchwork.kernel.org/project/linux-fsdevel/patch/20190903113640.7984-3-mszeredi@redhat.com/ Fixes: 79c0b2df79eb ("add filesystem subtype support") Cc: David Howells Cc: Signed-off-by: ChenXiaoSong Signed-off-by: Greg Kroah-Hartman

mm: userfaultfd: fix missing cache flush in mcopy_atomic_pte() and __mcopy_atomic()

2022-05-15T17:41:58+00:00

commit 7c25a0b89a487878b0691e6524fb5a8827322194 upstream. userfaultfd calls mcopy_atomic_pte() and __mcopy_atomic() which do not do any cache flushing for the target page. Then the target page will be mapped to the user space with a different address (user address), which might have an alias issue with the kernel address used to copy the data from the user to. Fix this by insert flush_dcache_page() after copy_from_user() succeeds. Link: https://lkml.kernel.org/r/20220210123058.79206-7-songmuchun@bytedance.com Fixes: b6ebaedb4cb1 ("userfaultfd: avoid mmap_sem read recursion in mcopy_atomic") Fixes: c1a4de99fada ("userfaultfd: mcopy_atomic|mfill_zeropage: UFFDIO_COPY|UFFDIO_ZEROPAGE preparation") Signed-off-by: Muchun Song Cc: Axel Rasmussen Cc: David Rientjes Cc: Fam Zheng Cc: Kirill A. Shutemov Cc: Lars Persson Cc: Mike Kravetz Cc: Peter Xu Cc: Xiongchun Duan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

mm: hugetlb: fix missing cache flush in copy_huge_page_from_user()

2022-05-15T17:41:58+00:00

commit e763243cc6cb1fcc720ec58cfd6e7c35ae90a479 upstream. userfaultfd calls copy_huge_page_from_user() which does not do any cache flushing for the target page. Then the target page will be mapped to the user space with a different address (user address), which might have an alias issue with the kernel address used to copy the data from the user to. Fix this issue by flushing dcache in copy_huge_page_from_user(). Link: https://lkml.kernel.org/r/20220210123058.79206-4-songmuchun@bytedance.com Fixes: fa4d75c1de13 ("userfaultfd: hugetlbfs: add copy_huge_page_from_user for hugetlb userfaultfd support") Signed-off-by: Muchun Song Reviewed-by: Mike Kravetz Cc: Axel Rasmussen Cc: David Rientjes Cc: Fam Zheng Cc: Kirill A. Shutemov Cc: Lars Persson Cc: Peter Xu Cc: Xiongchun Duan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock

2022-05-15T17:41:58+00:00

commit bc55cfd5718c7c23e5524582e9fa70b4d10f2433 upstream. syzbot caught a potential deadlock between the PCM runtime->buffer_mutex and the mm->mmap_lock. It was brought by the recent fix to cover the racy read/write and other ioctls, and in that commit, I overlooked a (hopefully only) corner case that may take the revert lock, namely, the OSS mmap. The OSS mmap operation exceptionally allows to re-configure the parameters inside the OSS mmap syscall, where mm->mmap_mutex is already held. Meanwhile, the copy_from/to_user calls at read/write operations also take the mm->mmap_lock internally, hence it may lead to a AB/BA deadlock. A similar problem was already seen in the past and we fixed it with a refcount (in commit b248371628aa). The former fix covered only the call paths with OSS read/write and OSS ioctls, while we need to cover the concurrent access via both ALSA and OSS APIs now. This patch addresses the problem above by replacing the buffer_mutex lock in the read/write operations with a refcount similar as we've used for OSS. The new field, runtime->buffer_accessing, keeps the number of concurrent read/write operations. Unlike the former buffer_mutex protection, this protects only around the copy_from/to_user() calls; the other codes are basically protected by the PCM stream lock. The refcount can be a negative, meaning blocked by the ioctls. If a negative value is seen, the read/write aborts with -EBUSY. In the ioctl side, OTOH, they check this refcount, too, and set to a negative value for blocking unless it's already being accessed. Reported-by: syzbot+6e5c88838328e99c7e1c@syzkaller.appspotmail.com Fixes: dca947d4d26d ("ALSA: pcm: Fix races among concurrent read/write and buffer changes") Cc: Link: https://lore.kernel.org/r/000000000000381a0d05db622a81@google.com Link: https://lore.kernel.org/r/20220330120903.4738-1-tiwai@suse.de Signed-off-by: Takashi Iwai [OP: backport to 4.19: adjusted context] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman

ALSA: pcm: Fix races among concurrent prealloc proc writes

2022-05-15T17:41:58+00:00

commit 69534c48ba8ce552ce383b3dfdb271ffe51820c3 upstream. We have no protection against concurrent PCM buffer preallocation changes via proc files, and it may potentially lead to UAF or some weird problem. This patch applies the PCM open_mutex to the proc write operation for avoiding the racy proc writes and the PCM stream open (and further operations). Cc: Reviewed-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20220322170720.3529-5-tiwai@suse.de Signed-off-by: Takashi Iwai [OP: backport to 4.19: adjusted context] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman

ALSA: pcm: Fix races among concurrent prepare and hw_params/hw_free calls

2022-05-15T17:41:58+00:00

commit 3c3201f8c7bb77eb53b08a3ca8d9a4ddc500b4c0 upstream. Like the previous fixes to hw_params and hw_free ioctl races, we need to paper over the concurrent prepare ioctl calls against hw_params and hw_free, too. This patch implements the locking with the existing runtime->buffer_mutex for prepare ioctls. Unlike the previous case for snd_pcm_hw_hw_params() and snd_pcm_hw_free(), snd_pcm_prepare() is performed to the linked streams, hence the lock can't be applied simply on the top. For tracking the lock in each linked substream, we modify snd_pcm_action_group() slightly and apply the buffer_mutex for the case stream_lock=false (formerly there was no lock applied) there. Cc: Reviewed-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20220322170720.3529-4-tiwai@suse.de Signed-off-by: Takashi Iwai [OP: backport to 4.19: adjusted context] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman

ALSA: pcm: Fix races among concurrent read/write and buffer changes

2022-05-15T17:41:58+00:00

commit dca947d4d26dbf925a64a6cfb2ddbc035e831a3d upstream. In the current PCM design, the read/write syscalls (as well as the equivalent ioctls) are allowed before the PCM stream is running, that is, at PCM PREPARED state. Meanwhile, we also allow to re-issue hw_params and hw_free ioctl calls at the PREPARED state that may change or free the buffers, too. The problem is that there is no protection against those mix-ups. This patch applies the previously introduced runtime->buffer_mutex to the read/write operations so that the concurrent hw_params or hw_free call can no longer interfere during the operation. The mutex is unlocked before scheduling, so we don't take it too long. Cc: Reviewed-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20220322170720.3529-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman

ALSA: pcm: Fix races among concurrent hw_params and hw_free calls

2022-05-15T17:41:58+00:00

commit 92ee3c60ec9fe64404dc035e7c41277d74aa26cb upstream. Currently we have neither proper check nor protection against the concurrent calls of PCM hw_params and hw_free ioctls, which may result in a UAF. Since the existing PCM stream lock can't be used for protecting the whole ioctl operations, we need a new mutex to protect those racy calls. This patch introduced a new mutex, runtime->buffer_mutex, and applies it to both hw_params and hw_free ioctl code paths. Along with it, the both functions are slightly modified (the mmap_count check is moved into the state-check block) for code simplicity. Reported-by: Hu Jiahui Cc: Reviewed-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20220322170720.3529-2-tiwai@suse.de Signed-off-by: Takashi Iwai [OP: backport to 4.19: adjusted context] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix the creation of hdev->name

2022-05-15T17:41:58+00:00

commit 103a2f3255a95991252f8f13375c3a96a75011cd upstream. Set a size limit of 8 bytes of the written buffer to "hdev->name" including the terminating null byte, as the size of "hdev->name" is 8 bytes. If an id value which is greater than 9999 is allocated, then the "snprintf(hdev->name, sizeof(hdev->name), "hci%d", id)" function call would lead to a truncation of the id value in decimal notation. Set an explicit maximum id parameter in the id allocation function call. The id allocation function defines the maximum allocated id value as the maximum id parameter value minus one. Therefore, HCI_MAX_ID is defined as 10000. Signed-off-by: Itay Iellin Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman