CVE-2020-36322

commit 5650152ddab1a6b367e6804deea344e001bd656e Author: Greg Kroah-Hartman Date: Sat Jan 9 13:46:25 2021 +0100 Linux 5.10.6 Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit 94cc73b27a2599e4c88b7b2d6fd190107c58e480 Author: Zhang Xiaohui Date: Sun Dec 6 16:48:01 2020 +0800 mwifiex: Fix possible buffer overflows in mwifiex_cmd_802_11_ad_hoc_start [ Upstream commit 5c455c5ab332773464d02ba17015acdca198f03d ] mwifiex_cmd_802_11_ad_hoc_start() calls memcpy() without checking the destination size may trigger a buffer overflower, which a local user could use to cause denial of service or the execution of arbitrary code. Fix it by putting the length check before calling memcpy(). Signed-off-by: Zhang Xiaohui Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin commit ab7709b551de24e7bebf44946120e6740b1e28db Author: Eric W. Biederman Date: Thu Dec 3 14:12:00 2020 -0600 exec: Transform exec_update_mutex into a rw_semaphore [ Upstream commit f7cfd871ae0c5008d94b6f66834e7845caa93c15 ] Recently syzbot reported[0] that there is a deadlock amongst the users of exec_update_mutex. The problematic lock ordering found by lockdep was: perf_event_open (exec_update_mutex -> ovl_i_mutex) chown (ovl_i_mutex -> sb_writes) sendfile (sb_writes -> p->lock) by reading from a proc file and writing to overlayfs proc_pid_syscall (p->lock -> exec_update_mutex) While looking at possible solutions it occured to me that all of the users and possible users involved only wanted to state of the given process to remain the same. They are all readers. The only writer is exec. There is no reason for readers to block on each other. So fix this deadlock by transforming exec_update_mutex into a rw_semaphore named exec_update_lock that only exec takes for writing. Cc: Jann Horn Cc: Vasiliy Kulikov Cc: Al Viro Cc: Bernd Edlinger Cc: Oleg Nesterov Cc: Christopher Yeoh Cc: Cyrill Gorcunov Cc: Sargun Dhillon Cc: Christian Brauner Cc: Arnd Bergmann Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Fixes: eea9673250db (“exec: Add exec_update_mutex to replace cred_guard_mutex”) [0] https://lkml.kernel.org/r/[email protected] Reported-by: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit 933b7cc86068fe9c2b8ebb51606022a37a7f958a Author: Eric W. Biederman Date: Thu Dec 3 14:11:13 2020 -0600 rwsem: Implement down_read_interruptible [ Upstream commit 31784cff7ee073b34d6eddabb95e3be2880a425c ] In preparation for converting exec_update_mutex to a rwsem so that multiple readers can execute in parallel and not deadlock, add down_read_interruptible. This is needed for perf_event_open to be converted (with no semantic changes) from working on a mutex to wroking on a rwsem. Signed-off-by: Eric W. Biederman Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin commit 27bae39e4fc4f911eae970ed2a332a36a92d463d Author: Eric W. Biederman Date: Thu Dec 3 14:10:32 2020 -0600 rwsem: Implement down_read_killable_nested [ Upstream commit 0f9368b5bf6db0c04afc5454b1be79022a681615 ] In preparation for converting exec_update_mutex to a rwsem so that multiple readers can execute in parallel and not deadlock, add down_read_killable_nested. This is needed so that kcmp_lock can be converted from working on a mutexes to working on rw_semaphores. Signed-off-by: Eric W. Biederman Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin commit 2cded5a3cc38545472a717b16402cbde1c1712b5 Author: [email protected] Date: Fri Aug 28 14:37:20 2020 +0200 perf: Break deadlock involving exec_update_mutex [ Upstream commit 78af4dc949daaa37b3fcd5f348f373085b4e858f ] Syzbot reported a lock inversion involving perf. The sore point being perf holding exec_update_mutex() for a very long time, specifically across a whole bunch of filesystem ops in pmu::event_init() (uprobes) and anon_inode_getfile(). This then inverts against procfs code trying to take exec_update_mutex. Move the permission checks later, such that we need to hold the mutex over less code. Reported-by: [email protected] Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Sasha Levin commit 36cf9ae54b0ead0daab7701a994de3dcd9ef605d Author: Miklos Szeredi Date: Thu Dec 10 15:33:14 2020 +0100 fuse: fix bad inode [ Upstream commit 5d069dbe8aaf2a197142558b6fb2978189ba3454 ] Jan Kara’s analysis of the syzbot report (edited): The reproducer opens a directory on FUSE filesystem, it then attaches dnotify mark to the open directory. After that a fuse_do_getattr() call finds that attributes returned by the server are inconsistent, and calls make_bad_inode() which, among other things does: inode->i_mode = S_IFREG; This then confuses dnotify which doesn’t tear down its structures properly and eventually crashes. Avoid calling make_bad_inode() on a live inode: switch to a private flag on the fuse inode. Also add the test to ops which the bad_inode_ops would have caught. This bug goes back to the initial merge of fuse in 2.6.14… Reported-by: [email protected] Signed-off-by: Miklos Szeredi Tested-by: Jan Kara Cc: Signed-off-by: Sasha Levin commit e522a788eb915dacde4a060e49f69ca1ea0cb34a Author: Jason Gunthorpe Date: Fri Nov 6 10:00:49 2020 -0400 RDMA/siw,rxe: Make emulated devices virtual in the device tree [ Upstream commit a9d2e9ae953f0ddd0327479c81a085adaa76d903 ] This moves siw and rxe to be virtual devices in the device tree: lrwxrwxrwx 1 root root 0 Nov 6 13:55 /sys/class/infiniband/rxe0 -> …/…/devices/virtual/infiniband/rxe0/ Previously they were trying to parent themselves to the physical device of their attached netdev, which doesn’t make alot of sense. My hope is this will solve some weird syzkaller hits related to sysfs as it could be possible that the parent of a netdev is another netdev, eg under bonding or some other syzkaller found netdev configuration. Nesting a ib_device under anything but a physical device is going to cause inconsistencies in sysfs during destructions. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 404fa093741e15e16fd522cc76cd9f86e9ef81d2 Author: Christoph Hellwig Date: Fri Nov 6 19:19:38 2020 +0100 RDMA/core: remove use of dma_virt_ops [ Upstream commit 5a7a9e038b032137ae9c45d5429f18a2ffdf7d42 ] Use the ib_dma_* helpers to skip the DMA translation instead. This removes the last user if dma_virt_ops and keeps the weird layering violation inside the RDMA core instead of burderning the DMA mapping subsystems with it. This also means the software RDMA drivers now don’t have to mess with DMA parameters that are not relevant to them at all, and that in the future we can use PCI P2P transfers even for software RDMA, as there is no first fake layer of DMA mapping that the P2P DMA support. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christoph Hellwig Tested-by: Mike Marciniszyn Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 2a54ad3066a810ffa8f5ee958def3dc3065d8cd6 Author: Stanley Chu Date: Tue Dec 8 21:56:34 2020 +0800 scsi: ufs: Re-enable WriteBooster after device reset [ Upstream commit bd14bf0e4a084514aa62d24d2109e0f09a93822f ] UFS 3.1 specification mentions that the WriteBooster flags listed below will be set to their default values, i.e. disabled, after power cycle or any type of reset event. Thus we need to reset the flag variables kept in struct hba to align with the device status and ensure that WriteBooster-related functions are configured properly after device reset. Without this fix, WriteBooster will not be enabled successfully after by ufshcd_wb_ctrl() after device reset because hba->wb_enabled remains true. Flags required to be reset to default values: - fWriteBoosterEn: hba->wb_enabled - fWriteBoosterBufferFlushEn: hba->wb_buf_flush_enabled - fWriteBoosterBufferFlushDuringHibernate: No variable mapped Link: https://lore.kernel.org/r/[email protected] Fixes: 3d17b9b5ab11 (“scsi: ufs: Add write booster feature support”) Reviewed-by: Bean Huo Signed-off-by: Stanley Chu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit acbf7db67ae334b1884321755b097142d4d79674 Author: Adrian Hunter Date: Tue Nov 3 16:14:03 2020 +0200 scsi: ufs: Allow an error return value from ->device_reset() [ Upstream commit 151f1b664ffbb847c7fbbce5a5b8580f1b9b1d98 ] It is simpler for drivers to provide a ->device_reset() callback irrespective of whether the GPIO, or firmware interface necessary to do the reset, is discovered during probe. Change ->device_reset() to return an error code. Drivers that provide the callback, but do not do the reset operation should return -EOPNOTSUPP. Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Asutosh Das Reviewed-by: Stanley Chu Reviewed-by: Bean huo Reviewed-by: Can Guo Signed-off-by: Adrian Hunter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8cba90399216ac12ad86193a5dcb0bb7606e15c9 Author: Imre Deak Date: Sat Oct 3 03:18:46 2020 +0300 drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock commit 0e2497e334de42dbaaee8e325241b5b5b34ede7e upstream. Apply Display WA #22010492432 for combo PHY PLLs too. This should fix a problem where the PLL output frequency is slightly off with the current PLL fractional divider value. I haven’t seen an actual case where this causes a problem, but let’s follow the spec. It’s also needed on some EHL platforms, but for that we also need a way to distinguish the affected EHL SKUs, so I leave that for a follow-up. v2: - Apply the WA at one place when calculating the PLL dividers from the frequency and the frequency from the dividers for all the combo PLL use cases (DP, HDMI, TBT). (Ville) Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman commit adee1c5126ef0aa7951e0ba101b73a3cd6732c09 Author: Takashi Iwai Date: Fri Jan 1 09:38:52 2021 +0100 ALSA: hda/hdmi: Fix incorrect mutex unlock in silent_stream_disable() commit 3d5c5fdcee0f9a94deb0472e594706018b00aa31 upstream. The silent_stream_disable() function introduced by the commit b1a5039759cb (“ALSA: hda/hdmi: fix silent stream for first playback to DP”) takes the per_pin->lock mutex, but it unlocks the wrong one, spec->pcm_lock, which causes a deadlock. This patch corrects it. Fixes: b1a5039759cb (“ALSA: hda/hdmi: fix silent stream for first playback to DP”) Reported-by: Jan Alexander Steffens (heftig) Cc: Acked-by: Kai Vehmanen Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e235fd076eb7ad6e730bb1e0bfedd66519b236f4 Author: Kailang Yang Date: Wed Dec 23 15:34:57 2020 +0800 ALSA: hda/realtek - Modify Dell platform name commit c1e8952395c1f44a6304c71401519d19ed2ac56a upstream. Dell platform SSID:0x0a58 change platform name. Use the generic name instead for avoiding confusion. Fixes: 150927c3674d (“ALSA: hda/realtek - Supported Dell fixed type headset”) Signed-off-by: Kailang Yang Cc: Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ce9163cf7a84e43ac7329aa0f585dff734c72c4e Author: Edward Vear Date: Tue Oct 27 00:02:03 2020 -0700 Bluetooth: Fix attempting to set RPA timeout when unsupported commit a31489d2a368d2f9225ed6a6f595c63bc7d10de8 upstream. During controller initialization, an LE Set RPA Timeout command is sent to the controller if supported. However, the value checked to determine if the command is supported is incorrect. Page 1921 of the Bluetooth Core Spec v5.2 shows that bit 2 of octet 35 of the Supported_Commands field corresponds to the LE Set RPA Timeout command, but currently bit 6 of octet 35 is checked. This patch checks the correct value instead. This issue led to the error seen in the following btmon output during initialization of an adapter (rtl8761b) and prevented initialization from completing. < HCI Command: LE Set Resolvable Private Address Timeout (0x08|0x002e) plen 2 Timeout: 900 seconds > HCI Event: Command Complete (0x0e) plen 4 LE Set Resolvable Private Address Timeout (0x08|0x002e) ncmd 2 Status: Unsupported Remote Feature / Unsupported LMP Feature (0x1a) = Close Index: 00:E0:4C:6B:E5:03 The error did not appear when running with this patch. Signed-off-by: Edward Vear Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg Cc: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 3e073508920aeafa8c6896a8897ee71e8b864559 Author: Josh Poimboeuf Date: Tue Dec 29 15:14:55 2020 -0800 kdev_t: always inline major/minor helper functions commit aa8c7db494d0a83ecae583aa193f1134ef25d506 upstream. Silly GCC doesn’t always inline these trivial functions. Fixes the following warning: arch/x86/kernel/sys_ia32.o: warning: objtool: cp_stat64()+0xd8: call to new_encode_dev() with UACCESS enabled Link: https://lkml.kernel.org/r/984353b44a4484d86ba9f73884b7306232e25e30.1608737428.git.jpoimboe@redhat.com Signed-off-by: Josh Poimboeuf Reported-by: Randy Dunlap Acked-by: Randy Dunlap [build-tested] Cc: Peter Zijlstra Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fd3ec3b2513799a97e4d734dfc4a116512dcc5f2 Author: Rasmus Villemoes Date: Fri Dec 18 11:10:53 2020 +0100 dt-bindings: rtc: add reset-source property commit 320d159e2d63a97a40f24cd6dfda5a57eec65b91 upstream. Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But if the reset pin is not actually wired up, the driver exposes a watchdog device that doesn’t actually work. Provide a standard binding that can be used to indicate that a given RTC can perform a reset of the machine, similar to wakeup-source. Suggested-by: Alexandre Belloni Signed-off-by: Rasmus Villemoes Reviewed-by: Rob Herring Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit 757cd94ac8598b0365e8b2b46564ff537d74805c Author: Uwe Kleine-König Date: Fri Dec 18 11:10:54 2020 +0100 rtc: pcf2127: only use watchdog when explicitly available commit 71ac13457d9d1007effde65b54818106b2c2b525 upstream. Most boards using the pcf2127 chip (in my bubble) don’t make use of the watchdog functionality and the respective output is not connected. The effect on such a board is that there is a watchdog device provided that doesn’t work. So only register the watchdog if the device tree has a “reset-source” property. Signed-off-by: Uwe Kleine-König [RV: s/has-watchdog/reset-source/] Signed-off-by: Rasmus Villemoes Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit acb821425c8cc5a4b688c973446cde356a04923a Author: Uwe Kleine-König Date: Thu Sep 24 12:52:55 2020 +0200 rtc: pcf2127: move watchdog initialisation to a separate function commit 5d78533a0c53af9659227c803df944ba27cd56e0 upstream. The obvious advantages are: - The linker can drop the watchdog functions if CONFIG_WATCHDOG is off. - All watchdog stuff grouped together with only a single function call left in generic code. - Watchdog register is only read when it is actually used. - Less #ifdefery Signed-off-by: Uwe Kleine-König Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/[email protected] Cc: Rasmus Villemoes Signed-off-by: Greg Kroah-Hartman commit b00195241186db6e2fb5698afe67971b05b1a959 Author: Felix Fietkau Date: Tue Jan 5 11:18:21 2021 +0100 Revert “mtd: spinand: Fix OOB read” This reverts stable commit baad618d078c857f99cc286ea249e9629159901f. This commit is adding lines to spinand_write_to_cache_op, wheras the upstream commit 868cbe2a6dcee451bd8f87cbbb2a73cf463b57e5 that this was supposed to backport was touching spinand_read_from_cache_op. It causes a crash on writing OOB data by attempting to write to read-only kernel memory. Cc: Miquel Raynal Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 261f4d03ad23c63964a6e1dd7b3611b108b1cb57 Author: Alex Deucher Date: Tue Jan 5 11:45:45 2021 -0500 Revert “drm/amd/display: Fix memory leaks in S3 resume” This reverts commit a135a1b4c4db1f3b8cbed9676a40ede39feb3362. This leads to blank screens on some boards after replugging a display. Revert until we understand the root cause and can fix both the leak and the blank screen after replug. Cc: Stylon Wang Cc: Harry Wentland Cc: Nicholas Kazlauskas Cc: Andre Tomt Cc: Oleksandr Natalenko Signed-off-by: Alex Deucher Cc: [email protected] Signed-off-by: Greg Kroah-Hartman