- 03 6月, 2021 40 次提交
-
-
由 Jonathan Cameron 提交于
stable inclusion from stable-5.10.37 commit 62a560ac4acdd9c938c6c7b3513b9ec2cd1d6f28 bugzilla: 51868 CVE: NA -------------------------------- commit 4e102429 upstream. Whilst running some basic tests as part of writing up the dt-bindings for this driver (to follow), it became clear it doesn't actually load currently. iio iio:device1: tried to double register : in_incli_x_index adis16201 spi0.0: Failed to create buffer sysfs interfaces adis16201: probe of spi0.0 failed with error -16 Looks like a cut and paste / update bug. Fixes tag obviously not accurate but we don't want to bother carry thing back to before the driver moved out of staging. Fixes: 591298e5 ("Staging: iio: accel: adis16201: Move adis16201 driver out of staging") Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Cc: <Stable@vger.kernel.org> Cc: Himanshu Jha <himanshujha199640@gmail.com> Cc: Nuno Sá <nuno.sa@analog.com> Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210321182956.844652-1-jic23@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lars-Peter Clausen 提交于
stable inclusion from stable-5.10.37 commit 5670ed4d556870478e54b4142a951e982be8e7aa bugzilla: 51868 CVE: NA -------------------------------- commit e09fe913 upstream. When setting the gyro or accelerometer scale the inv_mpu6050 driver ignores the integer part of the value. As a result e.g. all of 0.13309, 1.13309, 12345.13309, ... are accepted as a valid gyro scale and 0.13309 is the scale that gets set in all those cases. Make sure to check that the integer part of the scale value is 0 and reject it otherwise. Fixes: 09a642b7 ("Invensense MPU6050 Device Driver.") Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Acked-by: NJean-Baptiste Maneyrol <jmaneyrol@invensense.com> Link: https://lore.kernel.org/r/20210405114441.24167-1-lars@metafoo.de Cc: <Stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dmitry Osipenko 提交于
stable inclusion from stable-5.10.37 commit a1ad124c836816fac8bd5e461d36eaf33cee4e24 bugzilla: 51868 CVE: NA -------------------------------- commit ef85bb58 upstream. Fix voltage coupler lockup which happens when voltage-spread is out of range due to a bug in the code. The max-spread requirement shall be accounted when CPU regulator doesn't have consumers. This problem is observed on Tegra30 Ouya game console once system-wide DVFS is enabled in a device-tree. Fixes: 78380743 ("soc/tegra: regulators: Add regulators coupler for Tegra30") Cc: stable@vger.kernel.org Reported-by: NPeter Geis <pgwipeout@gmail.com> Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30 Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 Signed-off-by: NDmitry Osipenko <digetx@gmail.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lukasz Luba 提交于
stable inclusion from stable-5.10.37 commit 2f2d444ac4964ddd489090b16cc8ab2b06cbca04 bugzilla: 51868 CVE: NA -------------------------------- commit 8b50a799 upstream. The devfreq->lock is held for time of setup. Release the lock in the error path, before jumping to the end of the function. Change the goto destination which frees the allocated memory. Cc: v5.9+ <stable@vger.kernel.org> # v5.9+ Fixes: 4dc3bab8 ("PM / devfreq: Add support delayed timer for polling mode") Signed-off-by: NLukasz Luba <lukasz.luba@arm.com> Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Kishon Vijay Abraham I 提交于
stable inclusion from stable-5.10.37 commit e0b325888b53e7e63e6085588b7736e7e778e0df bugzilla: 51868 CVE: NA -------------------------------- commit 3d0b2a3a upstream. Both TI's AM65x (K3) and TI's K2 PCIe driver are implemented in pci-keystone. However Only K2 PCIe driver should use it's own pci_ops for configuration space accesses. But commit 10a797c6 ("PCI: dwc: keystone: Use pci_ops for config space accessors") used custom pci_ops for both AM65x and K2. This breaks configuration space access for AM65x platform. Fix it here. Link: https://lore.kernel.org/r/20210317131518.11040-1-kishon@ti.com Fixes: 10a797c6 ("PCI: dwc: keystone: Use pci_ops for config space accessors") Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NKrzysztof Wilczyński <kw@linux.com> Cc: <stable@vger.kernel.org> # v5.10 Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dejin Zheng 提交于
stable inclusion from stable-5.10.37 commit cc178b77f8a3ba11ea19f600c65aeff1d1b16ab2 bugzilla: 51868 CVE: NA -------------------------------- commit d4707d79 upstream. In commit e2dcd20b a change was made to use devm_platform_ioremap_resource_byname() to simplify code and remove the res variable; this was wrong since the res variable is still needed and as an outcome the port->cfg_addr gets an erroneous address. Revert the change going back to original behaviour. Link: https://lore.kernel.org/r/20210328144118.305074-1-zhengdejin5@gmail.com Fixes: e2dcd20b ("PCI: controller: Convert to devm_platform_ioremap_resource_byname()") Reported-by: dann.frazier@canonical.com Tested-by: Ndann frazier <dann.frazier@canonical.com> Signed-off-by: NDejin Zheng <zhengdejin5@gmail.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Sean Christopherson 提交于
stable inclusion from stable-5.10.37 commit 451a3e7570fc404a8a17b3dc9615ad6c79f3ebfc bugzilla: 51868 CVE: NA -------------------------------- commit f66c53b3 upstream. Defer unloading the MMU after a INVPCID until the instruction emulation has completed, i.e. until after RIP has been updated. On VMX, this is a benign bug as VMX doesn't touch the MMU when skipping an emulated instruction. However, on SVM, if nrip is disabled, the emulator is used to skip an instruction, which would lead to fireworks if the emulator were invoked without a valid MMU. Fixes: eb4b248e ("kvm: vmx: Support INVPCID in shadow paging mode") Cc: stable@vger.kernel.org Signed-off-by: NSean Christopherson <seanjc@google.com> Message-Id: <20210305011101.3597423-15-seanjc@google.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Arun Easi 提交于
stable inclusion from stable-5.10.37 commit 14e3676e3cadb81f39b522dd66204853eaf6e104 bugzilla: 51868 CVE: NA -------------------------------- commit e00dc69b upstream. 0d5370d1 ("PCI: Prevent VPD access for QLogic ISP2722") disabled access to VPD of the ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter because reading past the end of the VPD caused NMIs. 104daa71 ("PCI: Determine actual VPD size on first access") limits reads to the actual size of VPD, which should prevent these NMIs. 104daa71 was merged *before* 0d5370d1, but we think the testing that prompted 0d5370d1 ("PCI: Prevent VPD access for QLogic ISP2722") was done with a kernel that lacked 104daa71. See [1, 2]. Remove the quirk added by 0d5370d1 ("PCI: Prevent VPD access for QLogic ISP2722") so customers can read the HBA VPD. [1] https://lore.kernel.org/linux-pci/alpine.LRH.2.21.9999.2012161641230.28924@irv1user01.caveonetworks.com/ [2] https://lore.kernel.org/linux-pci/alpine.LRH.2.21.9999.2104071535110.13940@irv1user01.caveonetworks.com/ [bhelgaas: commit log] Link: https://lore.kernel.org/r/20210409215153.16569-2-aeasi@marvell.comSigned-off-by: NArun Easi <aeasi@marvell.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v4.6+ Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Maciej W. Rozycki 提交于
stable inclusion from stable-5.10.37 commit a22fc2eb03c4e9217ed6fd2a80fa216ac343f807 bugzilla: 51868 CVE: NA -------------------------------- commit f626ca68 upstream. Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. For those systems the PCI BARs that request a mapping in the I/O space have the length recorded in the corresponding PCI resource set to zero, which makes it unassigned: # lspci -s 0031:02:04.0 -v 0031:02:04.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ Interface Chip [PFI] FDDI (DEFPA) (rev 02) Subsystem: Digital Equipment Corporation FDDIcontroller/PCI (DEFPA) Flags: bus master, medium devsel, latency 136, IRQ 57, NUMA node 8 Memory at 620c080020000 (32-bit, non-prefetchable) [size=128] I/O ports at <unassigned> [disabled] Memory at 620c080030000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Kernel driver in use: defxx Kernel modules: defxx # Regardless the driver goes ahead and requests it (here observed with a Raptor Talos II POWER9 system), resulting in an odd /proc/ioport entry: # cat /proc/ioports 00000000-ffffffffffffffff : 0031:02:04.0 # Furthermore, the system gets confused as the driver actually continues and pokes at those locations, causing a flood of messages being output to the system console by the underlying system firmware, like: defxx: v1.11 2014/07/01 Lawrence V. Stefani and others defxx 0031:02:04.0: enabling device (0140 -> 0142) LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010000 IPMI: dropping non severe PEL event LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 IPMI: dropping non severe PEL event LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 IPMI: dropping non severe PEL event and so on and so on (possibly intermixed actually, as there's no locking between the kernel and the firmware in console port access with this particular system, but cleaned up above for clarity), and once some 10k of such pairs of the latter two messages have been produced an interace eventually shows up in a useless state: 0031:02:04.0: DEFPA at I/O addr = 0x0, IRQ = 57, Hardware addr = 00-00-00-00-00-00 This was not expected to happen as resource handling was added to the driver a while ago, because it was not known at that time that a PCI system would be possible that cannot assign port I/O resources, and oddly enough `request_region' does not fail, which would have caught it. Correct the problem then by checking for the length of zero for the CSR resource and bail out gracefully refusing to register an interface if that turns out to be the case, producing messages like: defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 0031:02:04.0: Cannot use I/O, no address set, aborting 0031:02:04.0: Recompile driver with "CONFIG_DEFXX_MMIO=y" Keep the original check for the EISA MMIO resource as implemented, because in that case the length is hardwired to 0x400 as a consequence of how the compare/mask address decoding works in the ESIC chip and it is only the base address that is set to zero if MMIO has been disabled for the adapter in EISA configuration, which in turn could be a valid bus address in a legacy-free system implementing PCI, especially for port I/O. Where the EISA MMIO resource has been disabled for the adapter in EISA configuration this arrangement keeps producing messages like: eisa 00:05: EISA: slot 5: DEC3002 detected defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 00:05: Cannot use MMIO, no address set, aborting 00:05: Recompile driver with "CONFIG_DEFXX_MMIO=n" 00:05: Or run ECU and set adapter's MMIO location with the last two lines now swapped for easier handling in the driver. There is no need to check for and catch the case of a port I/O resource not having been assigned for EISA as the adapter uses the slot-specific I/O space, which gets assigned by how EISA has been specified and maps directly to the particular slot an option card has been placed in. And the EISA variant of the adapter has additional registers that are only accessible via the port I/O space anyway. While at it factor out the error message calls into helpers and fix an argument order bug with the `pr_err' call now in `dfx_register_res_err'. Signed-off-by: NMaciej W. Rozycki <macro@orcam.me.uk> Fixes: 4d0438e5 ("defxx: Clean up DEFEA resource management") Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ilya Lipnitskiy 提交于
stable inclusion from stable-5.10.37 commit bd93fbc101d0916b23f2c4764ee800cd58225a24 bugzilla: 51868 CVE: NA -------------------------------- commit 8e98b697 upstream. pci_fixup_irqs() used to call pcibios_map_irq on every PCI device, which for RT2880 included bus 0 slot 0. After pci_fixup_irqs() got removed, only slots/funcs with devices attached would be called. While arguably the right thing, that left no chance for this driver to ever initialize slot 0, effectively bricking PCI and USB on RT2880 devices such as the Belkin F5D8235-4 v1. Slot 0 configuration needs to happen after PCI bus enumeration, but before any device at slot 0x11 (func 0 or 1) is talked to. That was determined empirically by testing on a Belkin F5D8235-4 v1 device. A minimal BAR 0 config write followed by read, then setting slot 0 PCI_COMMAND to MASTER | IO | MEMORY is all that seems to be required for proper functionality. Tested by ensuring that full- and high-speed USB devices get enumerated on the Belkin F5D8235-4 v1 (with an out of tree DTS file from OpenWrt). Fixes: 04c81c72 ("MIPS: PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks") Signed-off-by: NIlya Lipnitskiy <ilya.lipnitskiy@gmail.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Tobias Wolf <dev-NTEO@vplace.de> Cc: <stable@vger.kernel.org> # v4.14+ Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ilya Lipnitskiy 提交于
stable inclusion from stable-5.10.37 commit 149e1986ff6ae45ef63ef3eb819cbe2b808fa590 bugzilla: 51868 CVE: NA -------------------------------- commit c15b99ae upstream. Upstream a long-standing OpenWrt patch [0] that fixes MT7620 PCIe PLL lock check. The existing code checks the wrong register bit: PPLL_SW_SET is not defined in PPLL_CFG1 and bit 31 of PPLL_CFG1 is marked as reserved in the MT7620 Programming Guide. The correct bit to check for PLL lock is PPLL_LD (bit 23). Also reword the error message for clarity. Without this change it is unlikely that this driver ever worked with mainline kernel. [0]: https://lists.infradead.org/pipermail/lede-commits/2017-July/004441.htmlSigned-off-by: NIlya Lipnitskiy <ilya.lipnitskiy@gmail.com> Cc: John Crispin <john@phrozen.org> Cc: linux-mips@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Annaliese McDermond 提交于
stable inclusion from stable-5.10.37 commit cdc7ff119a65cfc49e1b860e11806737c623031d bugzilla: 51868 CVE: NA -------------------------------- commit 29654ed8 upstream. AIC32X4_REFPOWERUP was added as a register, but the maximum register value in the regmap and regmap range was not correspondingly increased. This caused an error when this register was attempted to be written. Fixes: ec96690d ("ASoC: tlv320aic32x4: Enable fast charge") Cc: stable@vger.kernel.org Signed-off-by: NAnnaliese McDermond <nh6z@nh6z.net> Link: https://lore.kernel.org/r/0101017889851cab-ce60cfdb-d88c-43d8-bbd2-7fbf34a0c912-000000@us-west-2.amazonses.comSigned-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Annaliese McDermond 提交于
stable inclusion from stable-5.10.37 commit 8d24a71959769ebe4fbf5e6350db0bd922625392 bugzilla: 51868 CVE: NA -------------------------------- commit 1ca1156c upstream. Clock registration must be performed before the component is registered. aic32x4_component_probe attempts to get all the clocks right off the bat. If the component is registered before the clocks there is a race condition where the clocks may not be registered by the time aic32x4_componet_probe actually runs. Fixes: d1c859d3 ("ASoC: codec: tlv3204: Increased maximum supported channels") Cc: stable@vger.kernel.org Signed-off-by: NAnnaliese McDermond <nh6z@nh6z.net> Link: https://lore.kernel.org/r/0101017889850206-dcac4cce-8cc8-4a21-80e9-4e4bef44b981-000000@us-west-2.amazonses.comSigned-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lukasz Majczak 提交于
stable inclusion from stable-5.10.37 commit c3c86bd3d5e4d7ffcbc2c8d0e3eda278b43b8930 bugzilla: 51868 CVE: NA -------------------------------- commit a523ef73 upstream. kabylake_ssp_fixup function uses snd_soc_dpcm to identify the codecs DAIs. The HW parameters are changed based on the codec DAI of the stream. The earlier approach to get snd_soc_dpcm was using container_of() macro on snd_pcm_hw_params. The structures have been modified over time and snd_soc_dpcm does not have snd_pcm_hw_params as a reference but as a copy. This causes the current driver to crash when used. This patch changes the way snd_soc_dpcm is extracted. snd_soc_pcm_runtime holds 2 dpcm instances (one for playback and one for capture). 2 codecs on the SSP are dmic (capture) and speakers (playback). Based on the stream direction, snd_soc_dpcm is extracted from snd_soc_pcm_runtime. Tested for all use cases of the driver. Based on similar fix in kbl_rt5663_rt5514_max98927.c from Harsha Priya <harshapriya.n@intel.com> and Vamshi Krishna Gopal <vamshi.krishna.gopal@intel.com> Cc: <stable@vger.kernel.org> # 5.4+ Signed-off-by: NLukasz Majczak <lma@semihalf.com> Acked-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210415124347.475432-1-lma@semihalf.comSigned-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Pierre-Louis Bossart 提交于
stable inclusion from stable-5.10.37 commit 7a7c14873c6d4f916dcd8264e56f5df06456aaae bugzilla: 51868 CVE: NA -------------------------------- commit d58970da upstream. cppcheck warning: sound/soc/samsung/tm2_wm5110.c:605:6: style: Variable 'ret' is reassigned a value before the old one has been used. [redundantAssignment] ret = devm_snd_soc_register_component(dev, &tm2_component, ^ sound/soc/samsung/tm2_wm5110.c:554:7: note: ret is assigned ret = of_parse_phandle_with_args(dev->of_node, "i2s-controller", ^ sound/soc/samsung/tm2_wm5110.c:605:6: note: ret is overwritten ret = devm_snd_soc_register_component(dev, &tm2_component, ^ The args is a stack variable, so it could have junk (uninitialized) therefore args.np could have a non-NULL and random value even though property was missing. Later could trigger invalid pointer dereference. There's no need to check for args.np because args.np won't be initialized on errors. Fixes: 8d1513ce ("ASoC: samsung: Add support for HDMI audio on TM2 board") Cc: <stable@vger.kernel.org> Suggested-by: NKrzysztof Kozlowski <krzk@kernel.org> Reviewed-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210312180231.2741-2-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chunfeng Yun 提交于
stable inclusion from stable-5.10.37 commit 5a75dc20a92bbedd90dc6699ed69d8aeb7565bf3 bugzilla: 51868 CVE: NA -------------------------------- commit e19ee44a upstream. When the USB headset is plug into an external hub, sometimes can't set config due to not enough bandwidth, so need improve LS/FS INT/ISOC bandwidth scheduling with TT. Fixes: 54f6a8af ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints") Cc: stable <stable@vger.kernel.org> Signed-off-by: NYaqii Wu <yaqii.wu@mediatek.com> Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/2f30e81400a59afef5f8231c98149169c7520519.1615170625.git.chunfeng.yun@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chunfeng Yun 提交于
stable inclusion from stable-5.10.37 commit eb58724f447645b8864e7771782789ca91c03954 bugzilla: 51868 CVE: NA -------------------------------- commit 5fa58275 upstream. Side effect may happen if use or operator to set schedule parameters when the parameters are already set before. Set them directly due to other bits are reserved. Fixes: 54f6a8af ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints") Cc: stable <stable@vger.kernel.org> Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/d287899e6beb2fc1bfb8900c75a872f628ecde55.1615170625.git.chunfeng.yun@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Badhri Jagan Sridharan 提交于
stable inclusion from stable-5.10.37 commit 048a99032d8a65df39fc5ee5bc27ccabd174c5d2 bugzilla: 51868 CVE: NA -------------------------------- commit 4050f268 upstream. power_supply_changed needs to be called to notify clients after the partner accepts the requested values for the pps case. Also, remove the redundant power_supply_changed at the end of the tcpm_reset_port as power_supply_changed is already called right after usb_type is changed. Fixes: f2a8aa05 ("typec: tcpm: Represent source supply through power_supply") Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com> Cc: stable <stable@vger.kernel.org> Reviewed-by: NAdam Thomson <Adam.Thomson.Opensource@diasemi.com> Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210407200723.1914388-3-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Badhri Jagan Sridharan 提交于
stable inclusion from stable-5.10.37 commit 61a4b925aa0f8071dec06189ad3959932e3c1d90 bugzilla: 51868 CVE: NA -------------------------------- commit e3a07202 upstream. tcpm_pd_select_pps_apdo overwrites port->pps_data.min_volt, port->pps_data.max_volt, port->pps_data.max_curr even before port partner accepts the requests. This leaves incorrect values in current_limit and supply_voltage that get exported by "tcpm-source-psy-". Solving this problem by caching the request values in req_min_volt, req_max_volt, req_max_curr, req_out_volt, req_op_curr. min_volt, max_volt, max_curr gets updated once the partner accepts the request. current_limit, supply_voltage gets updated once local port's tcpm enters SNK_TRANSITION_SINK when the accepted current_limit and supply_voltage is enforced. Fixes: f2a8aa05 ("typec: tcpm: Represent source supply through power_supply") Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com> Cc: stable <stable@vger.kernel.org> Reviewed-by: NAdam Thomson <Adam.Thomson.Opensource@diasemi.com> Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210407200723.1914388-2-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Badhri Jagan Sridharan 提交于
stable inclusion from stable-5.10.37 commit 79cae796dbf0b00ea972cd870b4c3e05572aafbd bugzilla: 51868 CVE: NA -------------------------------- commit f3dedafb upstream. tcpm_pd_build_request overwrites current_limit and supply_voltage even before port partner accepts the requests. This leaves stale values in current_limit and supply_voltage that get exported by "tcpm-source-psy-". Solving this problem by caching the request values of current limit/supply voltage in req_current_limit and req_supply_voltage. current_limit/supply_voltage gets updated once the port partner accepts the request. Fixes: f2a8aa05 ("typec: tcpm: Represent source supply through power_supply") Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com> Cc: stable <stable@vger.kernel.org> Reviewed-by: NGuenter Roeck <linux@roeck-us.net> Reviewed-by: NAdam Thomson <Adam.Thomson.Opensource@diasemi.com> Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210407200723.1914388-1-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Randy Dunlap 提交于
stable inclusion from stable-5.10.37 commit 0dace269aa22d490af49f4d0faf4985ee648e223 bugzilla: 51868 CVE: NA -------------------------------- commit ad085b3a upstream. The Lontium DRM bridge drivers use mipi_dsi_() function interfaces so they need to select DRM_MIPI_DSI to prevent build errors. ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined! ERROR: modpost: "mipi_dsi_device_register_full" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined! ERROR: modpost: "of_find_mipi_dsi_host_by_node" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined! ERROR: modpost: "mipi_dsi_device_unregister" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined! ERROR: modpost: "mipi_dsi_detach" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined! ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined! ERROR: modpost: "mipi_dsi_device_register_full" [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined! ERROR: modpost: "of_find_mipi_dsi_host_by_node" [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined! ERROR: modpost: "mipi_dsi_device_unregister" [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined! ERROR: modpost: "mipi_dsi_detach" [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined! WARNING: modpost: suppressed 5 unresolved symbol warnings because there were too many) Fixes: 23278bf5 ("drm/bridge: Introduce LT9611 DSI to HDMI bridge") Fixes: 0cbbd5b1 ("drm: bridge: add support for lontium LT9611UXC bridge") Fixes: 30e2ae94 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Reported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NRandy Dunlap <rdunlap@infradead.org> Reviewed-by: NAdren Grassein <adrien.grassein@gmail.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Vinod Koul <vkoul@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Adrien Grassein <adrien.grassein@gmail.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org Signed-off-by: NRobert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210415183639.1487-1-rdunlap@infradead.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Johan Hovold 提交于
stable inclusion from stable-5.10.37 commit 8a80901a061fdaf894c4b576a64f85eb7670651c bugzilla: 51868 CVE: NA -------------------------------- commit 2104eb28 upstream. Changing the port close-delay parameter is a privileged operation so make sure to return -EPERM if a regular user tries to change it. Fixes: 7355ba34 ("staging: fwserial: Add TTY-over-Firewire serial driver") Cc: stable@vger.kernel.org # 3.8 Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210407102334.32361-3-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Johan Hovold 提交于
stable inclusion from stable-5.10.37 commit af5145c8efa652f0adaec4f344fd2e2b4676a1b6 bugzilla: 51868 CVE: NA -------------------------------- commit dc8c8437 upstream. Changing the port close delay or type are privileged operations so make sure to return -EPERM if a regular user tries to change them. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210407102334.32361-12-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Johan Hovold 提交于
stable inclusion from stable-5.10.37 commit 6096118089c9558777bede5c0fdc19e63bc11dcb bugzilla: 51868 CVE: NA -------------------------------- commit 7a3791af upstream. The port close_delay parameter set by TIOCSSERIAL is specified in jiffies, while the value returned by TIOCGSERIAL is specified in centiseconds. Add the missing conversions so that TIOCGSERIAL works as expected also when HZ is not 100. Fixes: 7355ba34 ("staging: fwserial: Add TTY-over-Firewire serial driver") Cc: stable@vger.kernel.org # 3.8 Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210407102334.32361-2-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Johan Hovold 提交于
stable inclusion from stable-5.10.37 commit eb3a757e0baa7ef041cc46407e5962bb51c21c4e bugzilla: 51868 CVE: NA -------------------------------- commit d370c90d upstream. Changing the port closing-wait parameter is a privileged operation so make sure to return -EPERM if a regular user tries to change it. Cc: stable@vger.kernel.org Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Johan Hovold 提交于
stable inclusion from stable-5.10.37 commit 767e8241dd1cb433efff51544487c577642d384c bugzilla: 51868 CVE: NA -------------------------------- commit b71e571a upstream. The port close_delay and closing_wait parameters set by TIOCSSERIAL are specified in jiffies and not milliseconds. Add the missing conversions so that TIOCSSERIAL works as expected also when HZ is not 1000. Fixes: e68453ed ("greybus: uart-gb: now builds, more framework added") Cc: stable@vger.kernel.org # 4.9 Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210407102334.32361-6-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Johan Hovold 提交于
stable inclusion from stable-5.10.37 commit 304efedabad2e62d075418120a4e1dc3ab6b6297 bugzilla: 51868 CVE: NA -------------------------------- commit 3d732690 upstream. The port close_delay and closing_wait parameters set by TIOCSSERIAL are specified in jiffies and not milliseconds. Add the missing conversions so that the TIOCSSERIAL works as expected also when HZ is not 1000. Fixes: 02303f73 ("usb-wwan: implement TIOCGSERIAL and TIOCSSERIAL to avoid blocking close(2)") Cc: stable@vger.kernel.org # 2.6.38 Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Johan Hovold 提交于
stable inclusion from stable-5.10.37 commit f283aaa0182462493d25a0869a8e2a0f14488a85 bugzilla: 51868 CVE: NA -------------------------------- commit 1d31a831 upstream. Changing the port closing_wait parameter is a privileged operation. Add the missing check to TIOCSSERIAL so that -EPERM is returned in case an unprivileged user tries to change the closing-wait setting. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210407102334.32361-9-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Johan Hovold 提交于
stable inclusion from stable-5.10.37 commit f09ec0fc67a4b04e078489b92e9e94b15c14ca83 bugzilla: 51868 CVE: NA -------------------------------- commit 6e70b73c upstream. The port close_delay parameter set by TIOCSSERIAL is specified in jiffies, while the value returned by TIOCGSERIAL is specified in centiseconds. Add the missing conversions so that TIOCGSERIAL works as expected also when HZ is not 100. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210407102334.32361-11-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Hans de Goede 提交于
stable inclusion from stable-5.10.37 commit eeb4fd46eb9e393123acc8d59a1c29982dcdf58f bugzilla: 51868 CVE: NA -------------------------------- commit 3a2a91a2 upstream. usb_role_switch_find_by_fwnode() returns a reference to the role-switch which must be put by calling usb_role_switch_put(). usb_role_switch_put() calls module_put(sw->dev.parent->driver->owner), add a matching try_module_get() to usb_role_switch_find_by_fwnode(), making it behave the same as the other usb_role_switch functions which return a reference. This avoids a WARN_ON being hit at kernel/module.c:1158 due to the module-refcount going below 0. Fixes: c6919d5e ("usb: roles: Add usb_role_switch_find_by_fwnode()") Cc: stable <stable@vger.kernel.org> Reviewed-by: NGuenter Roeck <linux@roeck-us.net> Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210409124136.65591-1-hdegoede@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Johan Hovold 提交于
stable inclusion from stable-5.10.37 commit c2ef392fff9d6bc36d54b9f37bcde615ffcd4146 bugzilla: 51868 CVE: NA -------------------------------- commit 729f7955 upstream. This reverts commit b401f8c4. The offending commit claimed that trying to set the values reported back by TIOCGSERIAL as a regular user could result in an -EPERM error when HZ is 250, but that was never the case. With HZ=250, the default 0.5 second value of close_delay is converted to 125 jiffies when set and is converted back to 50 centiseconds by TIOCGSERIAL as expected (not 12 cs as was claimed, even if that was the case before an earlier fix). Comparing the internal current and new jiffies values is just fine to determine if the value is about to change so drop the bogus workaround (which was also backported to stable). For completeness: With different default values for these parameters or with a HZ value not divisible by two, the lack of rounding when setting the default values in tty_port_init() could result in an -EPERM being returned, but this is hardly something we need to worry about. Cc: Anthony Mallet <anthony.mallet@laas.fr> Cc: stable@vger.kernel.org Acked-by: NOliver Neukum <oneukum@suse.com> Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210408131602.27956-2-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
stable inclusion from stable-5.10.37 commit 7e916d0124e5f40d7912f93a633f5dee2c3ad735 bugzilla: 51868 CVE: NA -------------------------------- commit d1f82808 upstream. Read and write operations are capped to MAX_RW_COUNT. Some read ops rely on that limit, and that is not guaranteed by the IORING_OP_PROVIDE_BUFFERS. Truncate those lengths when doing io_add_buffers, so buffer addresses still use the uncapped length. Also, take the chance and change struct io_buffer len member to __u32, so it matches struct io_provide_buffer len member. This fixes CVE-2021-3491, also reported as ZDI-CAN-13546. Fixes: ddf0322d ("io_uring: add IORING_OP_PROVIDE_BUFFERS") Reported-by: Billy Jheng Bing-Jhong (@st424204) Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Or Cohen 提交于
stable inclusion from stable-5.10.37 commit 6b7021ed36dabf29e56842e3408781cd3b82ef6e bugzilla: 51868 CVE: NA -------------------------------- commit c61760e6 upstream. Commits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()") and c33b1cc6 ("nfc: fix refcount leak in llcp_sock_bind()") fixed a refcount leak bug in bind/connect but introduced a use-after-free if the same local is assigned to 2 different sockets. This can be triggered by the following simple program: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); close(sock2); Fix this by assigning NULL to llcp_sock->local after calling nfc_llcp_local_put. This addresses CVE-2021-23134. Reported-by: NOr Cohen <orcohen@paloaltonetworks.com> Reported-by: NNadav Markus <nmarkus@paloaltonetworks.com> Fixes: c33b1cc6 ("nfc: fix refcount leak in llcp_sock_bind()") Signed-off-by: NOr Cohen <orcohen@paloaltonetworks.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lin Ma 提交于
stable inclusion from stable-5.10.37 commit 2d84ef4e6569a818f912d93d5345c21542807ac7 bugzilla: 51868 CVE: NA -------------------------------- commit e2cb6b89 upstream. There is a possible race condition vulnerability between issuing a HCI command and removing the cont. Specifically, functions hci_req_sync() and hci_dev_do_close() can race each other like below: thread-A in hci_req_sync() | thread-B in hci_dev_do_close() | hci_req_sync_lock(hdev); test_bit(HCI_UP, &hdev->flags); | ... | test_and_clear_bit(HCI_UP, &hdev->flags) hci_req_sync_lock(hdev); | | In this commit we alter the sequence in function hci_req_sync(). Hence, the thread-A cannot issue th. Signed-off-by: NLin Ma <linma@zju.edu.cn> Cc: Marcel Holtmann <marcel@holtmann.org> Fixes: 7c6a329e ("[Bluetooth] Fix regression from using default link policy") Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Archie Pusaka 提交于
stable inclusion from stable-5.10.37 commit 1d7bd87a2c8d264ca3e5c9ba6f3eafc23e994028 bugzilla: 51868 CVE: NA -------------------------------- commit 5c4c8c95 upstream. hci_chan can be created in 2 places: hci_loglink_complete_evt() if it is an AMP hci_chan, or l2cap_conn_add() otherwise. In theory, Only AMP hci_chan should be removed by a call to hci_disconn_loglink_complete_evt(). However, the controller might mess up, call that function, and destroy an hci_chan which is not initiated by hci_loglink_complete_evt(). This patch adds a verification that the destroyed hci_chan must have been init'd by hci_loglink_complete_evt(). Example crash call trace: Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe3/0x144 lib/dump_stack.c:118 print_address_description+0x67/0x22a mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report mm/kasan/report.c:412 [inline] kasan_report+0x251/0x28f mm/kasan/report.c:396 hci_send_acl+0x3b/0x56e net/bluetooth/hci_core.c:4072 l2cap_send_cmd+0x5af/0x5c2 net/bluetooth/l2cap_core.c:877 l2cap_send_move_chan_cfm_icid+0x8e/0xb1 net/bluetooth/l2cap_core.c:4661 l2cap_move_fail net/bluetooth/l2cap_core.c:5146 [inline] l2cap_move_channel_rsp net/bluetooth/l2cap_core.c:5185 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:5464 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5799 [inline] l2cap_recv_frame+0x1d12/0x51aa net/bluetooth/l2cap_core.c:7023 l2cap_recv_acldata+0x2ea/0x693 net/bluetooth/l2cap_core.c:7596 hci_acldata_packet net/bluetooth/hci_core.c:4606 [inline] hci_rx_work+0x2bd/0x45e net/bluetooth/hci_core.c:4796 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321 kthread+0x2f0/0x304 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 Allocated by task 38: set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0x8d/0x9a mm/kasan/kasan.c:553 kmem_cache_alloc_trace+0x102/0x129 mm/slub.c:2787 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] hci_chan_create+0x86/0x26d net/bluetooth/hci_conn.c:1674 l2cap_conn_add.part.0+0x1c/0x814 net/bluetooth/l2cap_core.c:7062 l2cap_conn_add net/bluetooth/l2cap_core.c:7059 [inline] l2cap_connect_cfm+0x134/0x852 net/bluetooth/l2cap_core.c:7381 hci_connect_cfm+0x9d/0x122 include/net/bluetooth/hci_core.h:1404 hci_remote_ext_features_evt net/bluetooth/hci_event.c:4161 [inline] hci_event_packet+0x463f/0x72fa net/bluetooth/hci_event.c:5981 hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321 kthread+0x2f0/0x304 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 Freed by task 1732: set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free mm/kasan/kasan.c:521 [inline] __kasan_slab_free+0x106/0x128 mm/kasan/kasan.c:493 slab_free_hook mm/slub.c:1409 [inline] slab_free_freelist_hook+0xaa/0xf6 mm/slub.c:1436 slab_free mm/slub.c:3009 [inline] kfree+0x182/0x21e mm/slub.c:3972 hci_disconn_loglink_complete_evt net/bluetooth/hci_event.c:4891 [inline] hci_event_packet+0x6a1c/0x72fa net/bluetooth/hci_event.c:6050 hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321 kthread+0x2f0/0x304 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 The buggy address belongs to the object at ffff8881d7af9180 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 24 bytes inside of 128-byte region [ffff8881d7af9180, ffff8881d7af9200) The buggy address belongs to the page: page:ffffea00075ebe40 count:1 mapcount:0 mapping:ffff8881da403200 index:0x0 flags: 0x8000000000000200(slab) raw: 8000000000000200 dead000000000100 dead000000000200 ffff8881da403200 raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881d7af9080: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ffff8881d7af9100: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >ffff8881d7af9180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881d7af9200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8881d7af9280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Signed-off-by: NArchie Pusaka <apusaka@chromium.org> Reported-by: syzbot+98228e7407314d2d4ba2@syzkaller.appspotmail.com Reviewed-by: NAlain Michaud <alainm@chromium.org> Reviewed-by: NAbhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org> Cc: George Kennedy <george.kennedy@oracle.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lukasz Luba 提交于
stable inclusion from stable-5.10.36 commit 14b2801ccd9ba9ab13dc231e0a4c7cf1dc42d854 bugzilla: 51867 CVE: NA -------------------------------- commit fef05776 upstream. The tz->lock must be hold during the looping over the instances in that thermal zone. This lock was missing in the governor code since the beginning, so it's hard to point into a particular commit. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: NLukasz Luba <lukasz.luba@arm.com> Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210422153624.6074-2-lukasz.luba@arm.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 brian-sy yang 提交于
stable inclusion from stable-5.10.36 commit c24a20912eef00587416628149c438e885eb1304 bugzilla: 51867 CVE: NA -------------------------------- commit 34ab17cc upstream. Slab OOB issue is scanned by KASAN in cpu_power_to_freq(). If power is limited below the power of OPP0 in EM table, it will cause slab out-of-bound issue with negative array index. Return the lowest frequency if limited power cannot found a suitable OPP in EM table to fix this issue. Backtrace: [<ffffffd02d2a37f0>] die+0x104/0x5ac [<ffffffd02d2a5630>] bug_handler+0x64/0xd0 [<ffffffd02d288ce4>] brk_handler+0x160/0x258 [<ffffffd02d281e5c>] do_debug_exception+0x248/0x3f0 [<ffffffd02d284488>] el1_dbg+0x14/0xbc [<ffffffd02d75d1d4>] __kasan_report+0x1dc/0x1e0 [<ffffffd02d75c2e0>] kasan_report+0x10/0x20 [<ffffffd02d75def8>] __asan_report_load8_noabort+0x18/0x28 [<ffffffd02e6fce5c>] cpufreq_power2state+0x180/0x43c [<ffffffd02e6ead80>] power_actor_set_power+0x114/0x1d4 [<ffffffd02e6fac24>] allocate_power+0xaec/0xde0 [<ffffffd02e6f9f80>] power_allocator_throttle+0x3ec/0x5a4 [<ffffffd02e6ea888>] handle_thermal_trip+0x160/0x294 [<ffffffd02e6edd08>] thermal_zone_device_check+0xe4/0x154 [<ffffffd02d351cb4>] process_one_work+0x5e4/0xe28 [<ffffffd02d352f44>] worker_thread+0xa4c/0xfac [<ffffffd02d360124>] kthread+0x33c/0x358 [<ffffffd02d289940>] ret_from_fork+0xc/0x18 Fixes: 371a3bc7 ("thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power") Signed-off-by: Nbrian-sy yang <brian-sy.yang@mediatek.com> Signed-off-by: NMichael Kao <michael.kao@mediatek.com> Reviewed-by: NLukasz Luba <lukasz.luba@arm.com> Cc: stable@vger.kernel.org #v5.7 Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201229050831.19493-1-michael.kao@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Rasmus Villemoes 提交于
stable inclusion from stable-5.10.36 commit 051dd0681ce13e15aec4201f0b9cdfc8f5fda631 bugzilla: 51867 CVE: NA -------------------------------- commit 84696cfa upstream. Commit 9af77064 ("lib/vsprintf: Remove support for %pF and %pf in favour of %pS and %ps") removed support for %pF and %pf, and correctly removed the handling of those cases in vbin_printf(). However, the corresponding cases in bstr_printf() were left behind. In the same series, %pf was re-purposed for dealing with fwnodes (3bd32d6a, "lib/vsprintf: Add %pfw conversion specifier for printing fwnode names"). So should anyone use %pf with the binary printf routines, vbin_printf() would (correctly, as it involves dereferencing the pointer) do the string formatting to the u32 array, but bstr_printf() would not copy the string from the u32 array, but instead interpret the first sizeof(void*) bytes of the formatted string as a pointer - which generally won't end well (also, all subsequent get_args would be out of sync). Fixes: 9af77064 ("lib/vsprintf: Remove support for %pF and %pf in favour of %pS and %ps") Cc: stable@vger.kernel.org Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by: NSakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: NPetr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20210423094529.1862521-1-linux@rasmusvillemoes.dkSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Benjamin Block 提交于
stable inclusion from stable-5.10.36 commit 1cb02dc76f4c0a2749a02b26469512d6984252e9 bugzilla: 51867 CVE: NA -------------------------------- commit 8e947c8f upstream. When loading a device-mapper table for a request-based mapped device, and the allocation/initialization of the blk_mq_tag_set for the device fails, a following device remove will cause a double free. E.g. (dmesg): device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device device-mapper: ioctl: unable to set up device queue for new table. Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0305e098835de000 TEID: 0305e098835de803 Fault in home space mode while using kernel ASCE. AS:000000025efe0007 R3:0000000000000024 Oops: 0038 ilc:3 [#1] SMP Modules linked in: ... lots of modules ... Supported: Yes, External CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3 Hardware name: IBM 8561 T01 7I2 (LPAR) Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000 000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640 00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8 Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58 #000000025e368ec4: e3b010000008 ag %r11,0(%r1) >000000025e368eca: e310b0080004 lg %r1,8(%r11) 000000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4: a7740129 brc 7,25e369126 000000025e368ed8: e320b0080004 lg %r2,8(%r11) 000000025e368ede: b904001b lgr %r1,%r11 Call Trace: [<000000025e368eca>] kfree+0x42/0x330 [<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8 [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod] [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod] [<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod] [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod] [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod] [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40 [<000000025e8c15ac>] system_call+0xd8/0x2c8 Last Breaking-Event-Address: [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8 Kernel panic - not syncing: Fatal exception: panic_on_oops When allocation/initialization of the blk_mq_tag_set fails in dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer is not reset to NULL; so when dev_remove() later gets into dm_mq_cleanup_mapped_device() it sees the pointer and tries to uninitialize and free it again. Fix this by setting the pointer to NULL in dm_mq_init_request_queue() error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device(). Cc: <stable@vger.kernel.org> # 4.6+ Fixes: 1c357a1e ("dm: allocate blk_mq_tag_set rather than embed in mapped_device") Signed-off-by: NBenjamin Block <bblock@linux.ibm.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Tian Tao 提交于
stable inclusion from stable-5.10.36 commit 06141465e37251d3f4cb830fc762f5685d2fa4c3 bugzilla: 51867 CVE: NA -------------------------------- commit 17e9e134 upstream. Fixes: 468dfca3 ("dm integrity: add a bitmap mode") Cc: stable@vger.kernel.org Signed-off-by: NTian Tao <tiantao6@hisilicon.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-