- 03 6月, 2021 40 次提交
-
-
由 Jean-Philippe Brucker 提交于
maillist inclusion category: feature bugzilla: 51855 CVE: NA Reference: https://jpbrucker.net/git/linux/commit/?h=sva/2021-03-01&id=d32d8baaf293aaefef8a1c9b8a4508ab2ec46c61 --------------------------------------------- The ptep_set_access_flags path in handle_pte_fault, can cause a change of the pte's permissions on some architectures. A Read-Only and writeable-clean entry becomes Read-Write and dirty. This requires us to call the MMU notifier to invalidate the entry in remote TLBs, for instance in a PCIe Address Translation Cache (ATC). Here is a scenario where the lack of notifier call ends up locking a device: 1) A shared anonymous buffer is mapped with READ|WRITE prot, at VA. 2) A PCIe device with ATS/PRI/PASID capabilities wants to read the buffer, using its virtual address. a) Device asks for translation of VA for reading (NW=1) b) The IOMMU cannot fulfill the request, so the device does a Page Request for VA. The fault is handled with do_read_fault, after which the PTE has flags young, write and rdonly. c) Device retries the translation; IOMMU sends a Translation Completion with the PA and Read-Only permission. d) The VA->PA translation is stored in the ATC, with Read-Only permission. From the device's point of view, the page may or may not be writeable. It didn't ask for writeability, so it doesn't get a definite answer on that point. 3) The same device now wants to write the buffer. It needs to restart the AT-PR-AT dance for writing this time. a) Device could asks for translation of VA for reading and writing (NW=0). The IOMMU would reply with the same Read-Only mapping, so this time the device is certain that the page isn't writeable. Some implementations might update their ATC entry to store that information. The ATS specification is pretty fuzzy on the behaviour to adopt. b) The entry is Read-Only, so we fault again. The PTE exists and is valid, all we need to do is mark it dirty. TLBs are invalidated, but not the ATC since there is no notifier. c) Now the behaviour depends on the device implementation. If 3a) didn't update the ATC entry, the device is still uncertain on the writeability of the page, goto 3a) - repeat the Translation Request and get Read-Write permissions. But if 3a) updated the ATC entry, the device is certain of the PTE's permissions, and will goto 3b) instead - repeat the page fault, again and again. This time we take the "spurious fault" path in the same function, which invalidates the TLB but doesn't call an MMU notifier either. To avoid this page request loop, call mmu_notifier_change_pte after dirtying the PTE. Note: if the IOMMU supports hardware update of the access/dirty bits, 3a) dirties the PTE, and the IOMMU returns RW permission to the device, so there is no need to do a Page Request. Signed-off-by: NJean-Philippe Brucker <jean-philippe@linaro.org> Signed-off-by: NLijun Fang <fanglijun3@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jean-Philippe Brucker 提交于
maillist inclusion category: feature bugzilla: 51855 CVE: NA Reference: https://jpbrucker.net/git/linux/commit/?h=sva/2021-03-01&id=86593f8f8d03edca9cf1b29f87f524ac18fce3ae --------------------------------------------- The SMMU provides a Stall model for handling page faults in platform devices. It is similar to PCIe PRI, but doesn't require devices to have their own translation cache. Instead, faulting transactions are parked and the OS is given a chance to fix the page tables and retry the transaction. Enable stall for devices that support it (opt-in by firmware). When an event corresponds to a translation error, call the IOMMU fault handler. If the fault is recoverable, it will call us back to terminate or continue the stall. To use stall device drivers need to enable IOMMU_DEV_FEAT_IOPF, which initializes the fault queue for the device. Tested-by: NZhangfei Gao <zhangfei.gao@linaro.org> Reviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: NJean-Philippe Brucker <jean-philippe@linaro.org> Signed-off-by: NLijun Fang <fanglijun3@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jean-Philippe Brucker 提交于
maillist inclusion category: feature bugzilla: 51855 CVE: NA Reference: https://jpbrucker.net/git/linux/commit/?h=sva/2021-03-01&id=348aa067f7c0396819ac972b7d887a5f43a8c4f4 --------------------------------------------- Copy the "Stall supported" bit, that tells whether a named component supports stall, into the dma-can-stall device property. Acked-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: NJean-Philippe Brucker <jean-philippe@linaro.org> Signed-off-by: NLijun Fang <fanglijun3@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jean-Philippe Brucker 提交于
maillist inclusion category: feature bugzilla: 51855 CVE: NA Reference: https://jpbrucker.net/git/linux/commit/?h=sva/2021-03-01&id=ac36f448338ac053ec95f8abd331a77f2c1c5d8d --------------------------------------------- On ARM systems, some platform devices behind an IOMMU may support stall, which is the ability to recover from page faults. Let the firmware tell us when a device supports stall. Reviewed-by: NEric Auger <eric.auger@redhat.com> Reviewed-by: NRob Herring <robh@kernel.org> Signed-off-by: NJean-Philippe Brucker <jean-philippe@linaro.org> Signed-off-by: NLijun Fang <fanglijun3@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dongliang Mu 提交于
stable inclusion from stable-5.10.41 commit b34cb7ac32cc8e5471dc773180ea9ae676b1a745 bugzilla: 51890 CVE: NA -------------------------------- commit e0652f8b upstream. nfcmrvl_disconnect fails to free the hci_dev field in struct nci_dev. Fix this by freeing hci_dev in nci_free_device. BUG: memory leak unreferenced object 0xffff888111ea6800 (size 1024): comm "kworker/1:0", pid 19, jiffies 4294942308 (age 13.580s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 60 fd 0c 81 88 ff ff .........`...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000004bc25d43>] kmalloc include/linux/slab.h:552 [inline] [<000000004bc25d43>] kzalloc include/linux/slab.h:682 [inline] [<000000004bc25d43>] nci_hci_allocate+0x21/0xd0 net/nfc/nci/hci.c:784 [<00000000c59cff92>] nci_allocate_device net/nfc/nci/core.c:1170 [inline] [<00000000c59cff92>] nci_allocate_device+0x10b/0x160 net/nfc/nci/core.c:1132 [<00000000006e0a8e>] nfcmrvl_nci_register_dev+0x10a/0x1c0 drivers/nfc/nfcmrvl/main.c:153 [<000000004da1b57e>] nfcmrvl_probe+0x223/0x290 drivers/nfc/nfcmrvl/usb.c:345 [<00000000d506aed9>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<00000000bc632c92>] really_probe+0x159/0x4a0 drivers/base/dd.c:554 [<00000000f5009125>] driver_probe_device+0x84/0x100 drivers/base/dd.c:740 [<000000000ce658ca>] __device_attach_driver+0xee/0x110 drivers/base/dd.c:846 [<000000007067d05f>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 [<00000000f8e13372>] __device_attach+0x122/0x250 drivers/base/dd.c:914 [<000000009cf68860>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491 [<00000000359c965a>] device_add+0x5be/0xc30 drivers/base/core.c:3109 [<00000000086e4bd3>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2164 [<00000000ca036872>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [<00000000d40d36f6>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [<00000000bc632c92>] really_probe+0x159/0x4a0 drivers/base/dd.c:554 Reported-by: syzbot+19bcfc64a8df1318d1c3@syzkaller.appspotmail.com Fixes: 11f54f22 ("NFC: nci: Add HCI over NCI protocol support") Signed-off-by: NDongliang Mu <mudongliangabcd@gmail.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>
-
由 Dave Rigby 提交于
stable inclusion from stable-5.10.41 commit 8d11e6ae4304a575543e5ed4cc9a20a06d34297b bugzilla: 51890 CVE: NA -------------------------------- commit 4e148144 upstream. When locating the DWARF module for a given address, __find_debuginfo() requires a 'struct dso' passed via the userdata argument. However, this field is only set in __report_module() if the module is found in via dwfl_addrmodule(), not if it is found later via dwfl_report_elf(). Set userdata irrespective of how the DWARF module was found, as long as we found a module. Fixes: bf53fc6b ("perf unwind: Fix separate debug info files when using elfutils' libdw's unwinder") Signed-off-by: NDave Rigby <d.rigby@me.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211801Acked-by: NJan Kratochvil <jan.kratochvil@redhat.com> Acked-by: NJiri Olsa <jolsa@redhat.com> Link: https://lore.kernel.org/linux-perf-users/20210218165654.36604-1-d.rigby@me.com/Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com> Cc: "Tommi Rantala" <tommi.t.rantala@nokia.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>
-
由 Jan Kratochvil 提交于
stable inclusion from stable-5.10.41 commit 53eaf28c056d99a636970b06d5f9916b52973297 bugzilla: 51890 CVE: NA -------------------------------- commit bf53fc6b upstream. elfutils needs to be provided main binary and separate debug info file respectively. Providing separate debug info file instead of the main binary is not sufficient. One needs to try both supplied filename and its possible cache by its build-id depending on the use case. Signed-off-by: NJan Kratochvil <jan.kratochvil@redhat.com> Tested-by: NJiri Olsa <jolsa@redhat.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Ian Rogers <irogers@google.com> Cc: Namhyung Kim <namhyung@kernel.org> Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com> Cc: "Tommi Rantala" <tommi.t.rantala@nokia.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>
-
由 Wanpeng Li 提交于
stable inclusion from stable-5.10.41 commit 514883ebac77ff9939da92e268b24a71c9fe4e05 bugzilla: 51890 CVE: NA -------------------------------- commit 16045714 upstream. Defer the call to account guest time until after servicing any IRQ(s) that happened in the guest or immediately after VM-Exit. Tick-based accounting of vCPU time relies on PF_VCPU being set when the tick IRQ handler runs, and IRQs are blocked throughout the main sequence of vcpu_enter_guest(), including the call into vendor code to actually enter and exit the guest. This fixes a bug where reported guest time remains '0', even when running an infinite loop in the guest: https://bugzilla.kernel.org/show_bug.cgi?id=209831 Fixes: 87fa7f3e ("x86/kvm: Move context tracking where it belongs") Suggested-by: NThomas Gleixner <tglx@linutronix.de> Co-developed-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NWanpeng Li <wanpengli@tencent.com> Signed-off-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210505002735.1684165-4-seanjc@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>
-
由 Wanpeng Li 提交于
stable inclusion from stable-5.10.41 commit 77068304b30f553b05934224146813d3cdcaa12c bugzilla: 51890 CVE: NA -------------------------------- commit 88d8220b upstream. Provide separate vtime accounting functions for guest exit instead of open coding the logic within the context tracking code. This will allow KVM x86 to handle vtime accounting slightly differently when using tick-based accounting. Suggested-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NWanpeng Li <wanpengli@tencent.com> Co-developed-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com> Link: https://lore.kernel.org/r/20210505002735.1684165-3-seanjc@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>
-
由 Wanpeng Li 提交于
stable inclusion from stable-5.10.41 commit 5ae5e3f05831b7629cd33be0a8591905f0898599 bugzilla: 51890 CVE: NA -------------------------------- commit 866a6dad upstream. Provide separate context tracking helpers for guest exit, the standalone helpers will be called separately by KVM x86 in later patches to fix tick-based accounting. Suggested-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NWanpeng Li <wanpengli@tencent.com> Co-developed-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20210505002735.1684165-2-seanjc@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>
-
由 Daniel Borkmann 提交于
stable inclusion from stable-5.10.41 commit 27acfd11ba179b746f55077edf9750f8f7cb1cb6 bugzilla: 51890 CVE: NA -------------------------------- commit a7036191 upstream. In 801c6058 ("bpf: Fix leakage of uninitialized bpf stack under speculation") we replaced masking logic with direct loads of immediates if the register is a known constant. Given in this case we do not apply any masking, there is also no reason for the operation to be truncated under the speculative domain. Therefore, there is also zero reason for the verifier to branch-off and simulate this case, it only needs to do it for unknown but bounded scalars. As a side-effect, this also enables few test cases that were previously rejected due to simulation under zero truncation. Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Reviewed-by: NPiotr Krysiuk <piotras@gmail.com> Acked-by: NAlexei Starovoitov <ast@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>
-
由 Daniel Borkmann 提交于
stable inclusion from stable-5.10.41 commit c87ef240a8bbbda5913fac1e84209d224c1aaf50 bugzilla: 51890 CVE: NA -------------------------------- commit bb01a1bb upstream. Masking direction as indicated via mask_to_left is considered to be calculated once and then used to derive pointer limits. Thus, this needs to be placed into bpf_sanitize_info instead so we can pass it to sanitize_ptr_alu() call after the pointer move. Piotr noticed a corner case where the off reg causes masking direction change which then results in an incorrect final aux->alu_limit. Fixes: 7fedb63a ("bpf: Tighten speculative pointer arithmetic mask") Reported-by: NPiotr Krysiuk <piotras@gmail.com> Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Reviewed-by: NPiotr Krysiuk <piotras@gmail.com> Acked-by: NAlexei Starovoitov <ast@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>
-
由 Daniel Borkmann 提交于
stable inclusion from stable-5.10.41 commit 4e2c7b297431457663a90d4186e666b61d5da86c bugzilla: 51890 CVE: NA -------------------------------- commit 3d0220f6 upstream. Add a container structure struct bpf_sanitize_info which holds the current aux info, and update call-sites to sanitize_ptr_alu() to pass it in. This is needed for passing in additional state later on. Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Reviewed-by: NPiotr Krysiuk <piotras@gmail.com> Acked-by: NAlexei Starovoitov <ast@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>
-
由 Liu Shixin 提交于
hulk inclusion category: bugfix bugzilla: 51887 CVE: NA ------------------------------------------------- The commit f6366156 (mm/page_alloc.c: clear out zone->lowmem_reserve[] if the zone is empty) clear out zone->lowmem_reserve[] if zone is empty. But when zone is not empty and sysctl_lowmem_reserve_ratio[i] is set to zero, zone_managed_pages(zone) is not counted in the managed_pages either. This is inconsistent with the description of lowmen_reserve, so fix it. Fixes: f6366156 ("mm/page_alloc.c: clear out zone->lowmem_reserve[] if the zone is empty") Reported-by: Nyangerkun <yangerkun@huawei.com> Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lorenzo Stoakes 提交于
mainline inclusion from mainline-v5.11-rc1 commit 470c61d7 category: bugfix bugzilla: 51887 CVE: NA Refactor to adapt to commit ("mm/page_alloc: fix counting of managed_pages") Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=470c61d70299b1826f56ff5fede10786798e3c14 ------------------------------------------------- setup_per_zone_lowmem_reserve() iterates through each zone setting zone->lowmem_reserve[j] = 0 (where j is the zone's index) then iterates backwards through all preceding zones, setting lower_zone->lowmem_reserve[j] = sum(managed pages of higher zones) / lowmem_reserve_ratio[idx] for each (where idx is the lower zone's index). If the lower zone has no managed pages or its ratio is 0 then all of its lowmem_reserve[] entries are effectively zeroed. As these arrays are only assigned here and all lowmem_reserve[] entries for index < this zone's index are implicitly assumed to be 0 (as these are specifically output in show_free_areas() and zoneinfo_show_print() for example) there is no need to additionally zero index == this zone's index too. This patch avoids zeroing unnecessarily. Rather than iterating through zones and setting lowmem_reserve[j] for each lower zone this patch reverse the process and populates each zone's lowmem_reserve[] values in ascending order. This clarifies what is going on especially in the case of zero managed pages or ratio which is now explicitly shown to clear these values. Link: https://lkml.kernel.org/r/20201129162758.115907-1-lstoakes@gmail.comSigned-off-by: NLorenzo Stoakes <lstoakes@gmail.com> Cc: Baoquan He <bhe@redhat.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Roman Gushchin <guro@fb.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Reported-by: Nyangerkun <yangerkun@huawei.com> Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 JeongHyeon Lee 提交于
mainline inclusion from mainline-v5.13-rc1 commit 219a9b5e category: bugfix bugzilla: 51874 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=219a9b5e738b75a6a5e9effe1d72f60037a2f131 ----------------------------------------------- If more than one one handling mode is requested during DM verity table load, the last requested mode will be used. Change this to impose more strict checking so that the table load will fail if more than one error handling mode is requested. Signed-off-by: NJeongHyeon Lee <jhs2.lee@samsung.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Signed-off-by: NLuo Meng <luomeng12@huawei.com> Reviewed-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Luiz Augusto von Dentz 提交于
stable inclusion from stable-5.10.40 commit d8d261c7cfb3a5dd921b4aeeb944718afc3f3961 bugzilla: 51882 CVE: NA -------------------------------- commit 6d19628f upstream. This fails the pairing procedure when both remote and local non-debug public keys are identical. Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.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>
-
由 Anirudh Rayabharam 提交于
stable inclusion from stable-5.10.40 commit e8c34789f1b8662d4f79b9a64dc8be630d24841d bugzilla: 51882 CVE: NA -------------------------------- commit 02625c96 upstream. The return value of hga_card_detect() is not properly handled causing the probe to succeed even though hga_card_detect() failed. Since probe succeeds, hgafb_open() can be called which will end up operating on an unmapped hga_vram. This results in an out-of-bounds access as reported by kernel test robot [1]. To fix this, correctly detect failure of hga_card_detect() by checking for a non-zero error code. [1]: https://lore.kernel.org/lkml/20210516150019.GB25903@xsang-OptiPlex-9020/ Fixes: dc13cac4 ("video: hgafb: fix potential NULL pointer dereference") Cc: stable <stable@vger.kernel.org> Reported-by: Nkernel test robot <oliver.sang@intel.com> Reviewed-by: NIgor Matheus Andrade Torrente <igormtorrente@gmail.com> Signed-off-by: NAnirudh Rayabharam <mail@anirudhrb.com> Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20210516192714.25823-1-mail@anirudhrb.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>
-
由 Hou Pu 提交于
stable inclusion from stable-5.10.40 commit ed9fdd4c6f03e613403d03ee46bd41a2a3ed9211 bugzilla: 51882 CVE: NA -------------------------------- commit e181811b upstream. The new ana_log_size should be used instead of the old one. Or kernel NULL pointer dereference will happen like below: [ 38.957849][ T69] BUG: kernel NULL pointer dereference, address: 000000000000003c [ 38.975550][ T69] #PF: supervisor write access in kernel mode [ 38.975955][ T69] #PF: error_code(0x0002) - not-present page [ 38.976905][ T69] PGD 0 P4D 0 [ 38.979388][ T69] Oops: 0002 [#1] SMP NOPTI [ 38.980488][ T69] CPU: 0 PID: 69 Comm: kworker/0:2 Not tainted 5.12.0+ #54 [ 38.981254][ T69] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 38.982502][ T69] Workqueue: events nvme_loop_execute_work [ 38.985219][ T69] RIP: 0010:memcpy_orig+0x68/0x10f [ 38.986203][ T69] Code: 83 c2 20 eb 44 48 01 d6 48 01 d7 48 83 ea 20 0f 1f 00 48 83 ea 20 4c 8b 46 f8 4c 8b 4e f0 4c 8b 56 e8 4c 8b 5e e0 48 8d 76 e0 <4c> 89 47 f8 4c 89 4f f0 4c 89 57 e8 4c 89 5f e0 48 8d 7f e0 73 d2 [ 38.987677][ T69] RSP: 0018:ffffc900001b7d48 EFLAGS: 00000287 [ 38.987996][ T69] RAX: 0000000000000020 RBX: 0000000000000024 RCX: 0000000000000010 [ 38.988327][ T69] RDX: ffffffffffffffe4 RSI: ffff8881084bc004 RDI: 0000000000000044 [ 38.988620][ T69] RBP: 0000000000000024 R08: 0000000100000000 R09: 0000000000000000 [ 38.988991][ T69] R10: 0000000100000000 R11: 0000000000000001 R12: 0000000000000024 [ 38.989289][ T69] R13: ffff8881084bc000 R14: 0000000000000000 R15: 0000000000000024 [ 38.989845][ T69] FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 [ 38.990234][ T69] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 38.990490][ T69] CR2: 000000000000003c CR3: 00000001085b2000 CR4: 00000000000006f0 [ 38.991105][ T69] Call Trace: [ 38.994157][ T69] sg_copy_buffer+0xb8/0xf0 [ 38.995357][ T69] nvmet_copy_to_sgl+0x48/0x6d [ 38.995565][ T69] nvmet_execute_get_log_page_ana+0xd4/0x1cb [ 38.995792][ T69] nvmet_execute_get_log_page+0xc9/0x146 [ 38.995992][ T69] nvme_loop_execute_work+0x3e/0x44 [ 38.996181][ T69] process_one_work+0x1c3/0x3c0 [ 38.996393][ T69] worker_thread+0x44/0x3d0 [ 38.996600][ T69] ? cancel_delayed_work+0x90/0x90 [ 38.996804][ T69] kthread+0xf7/0x130 [ 38.996961][ T69] ? kthread_create_worker_on_cpu+0x70/0x70 [ 38.997171][ T69] ret_from_fork+0x22/0x30 [ 38.997705][ T69] Modules linked in: [ 38.998741][ T69] CR2: 000000000000003c [ 39.000104][ T69] ---[ end trace e719927b609d0fa0 ]--- Fixes: 5e1f6899 ("nvme-multipath: fix double initialization of ANA state") Signed-off-by: NHou Pu <houpu.main@gmail.com> Signed-off-by: NChristoph Hellwig <hch@lst.de> Cc: Guenter Roeck <linux@roeck-us.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>
-
由 Joerg Roedel 提交于
stable inclusion from stable-5.10.40 commit d28aa3c157363f23a476d3bea87335f1ac016a67 bugzilla: 51882 CVE: NA -------------------------------- commit fef81c86 upstream. Check whether the hypervisor reported the correct C-bit when running as an SEV guest. Using a wrong C-bit position could be used to leak sensitive data from the guest to the hypervisor. Signed-off-by: NJoerg Roedel <jroedel@suse.de> Signed-off-by: NBorislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20210312123824.306-8-joro@8bytes.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>
-
由 Francois Gervais 提交于
stable inclusion from stable-5.10.40 commit 0296c9057adee577bf53f7e91f6b1178e23aeb44 bugzilla: 51882 CVE: NA -------------------------------- commit 03531606 upstream. The rtc device node is always NULL. Since v5.12-rc1-dontuse/3c9ea428 this will lead to a NULL pointer dereference. To fix this use the parent node which is the i2c client node as set by devm_rtc_allocate_device(). Using the i2c client node seems to be what other similar drivers do e.g. rtc-pcf8563.c. Signed-off-by: NFrancois Gervais <fgervais@distech-controls.com> Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210310211026.27299-1-fgervais@distech-controls.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>
-
由 Christoph Hellwig 提交于
stable inclusion from stable-5.10.40 commit 7b994b03f1de4475dc261a0ff057751fdd0d2bfa bugzilla: 51882 CVE: NA -------------------------------- commit 5e1f6899 upstream. nvme_init_identify and thus nvme_mpath_init can be called multiple times and thus must not overwrite potentially initialized or in-use fields. Split out a helper for the basic initialization when the controller is initialized and make sure the init_identify path does not blindly change in-use data structures. Fixes: 0d0b660f ("nvme: add ANA support") Reported-by: NMartin Wilck <mwilck@suse.com> Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NKeith Busch <kbusch@kernel.org> Reviewed-by: NSagi Grimberg <sagi@grimberg.me> Reviewed-by: NHannes Reinecke <hare@suse.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>
-
由 Jan Beulich 提交于
stable inclusion from stable-5.10.40 commit e2c26ddd4e8565c54068d827da09bfabdf9d82de bugzilla: 51882 CVE: NA -------------------------------- commit ae897fda upstream. xen_setup_gdt(), via xen_load_gdt_boot(), wants to adjust page tables. For this to work when NX is not available, x86_configure_nx() needs to be called first. [jgross] Note that this is a revert of 36104cb9 ("x86/xen: Delay get_cpu_cap until stack canary is established"), which is possible now that we no longer support running as PV guest in 32-bit mode. Cc: <stable.vger.kernel.org> # 5.9 Fixes: 36104cb9 ("x86/xen: Delay get_cpu_cap until stack canary is established") Reported-by: NOlaf Hering <olaf@aepfle.de> Signed-off-by: NJan Beulich <jbeulich@suse.com> Reviewed-by: NJuergen Gross <jgross@suse.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/12a866b0-9e89-59f7-ebeb-a2a6cec0987a@suse.comSigned-off-by: NJuergen Gross <jgross@suse.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Mike Rapoport 提交于
stable inclusion from stable-5.10.40 commit d5c4605e9e1cf8f505df29fe21a091fa3edf2d2a bugzilla: 51882 CVE: NA -------------------------------- commit 4eff1243 upstream. Kernel test robot reports: cppcheck possible warnings: (new ones prefixed by >>, may not real problems) >> arch/openrisc/mm/init.c:125:10: warning: Uninitialized variable: region [uninitvar] region->base, region->base + region->size); ^ Replace usage of memblock_region fields with 'start' and 'end' variables that are initialized in for_each_mem_range() and remove the declaration of region. Fixes: b10d6bca ("arch, drivers: replace for_each_membock() with for_each_mem_range()") Reported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NMike Rapoport <rppt@linux.ibm.com> Signed-off-by: NStafford Horne <shorne@gmail.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>
-
由 Simon Rettberg 提交于
stable inclusion from stable-5.10.40 commit 585d8425e504c124817c962c4accb433d97c71ac bugzilla: 51882 CVE: NA -------------------------------- commit 023dfa96 upstream. When resetting CACHE_MODE registers, don't enable HiZ Raw Stall Optimization on Ivybridge GT1 and Baytrail, as it causes severe glitches when rendering any kind of 3D accelerated content. This optimization is disabled on these platforms by default according to official documentation from 01.org. Fixes: ef99a60f ("drm/i915/gt: Clear CACHE_MODE prior to clearing residuals") BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/3081 BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/3404 BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/3071Reviewed-by: NManuel Bentele <development@manuel-bentele.de> Signed-off-by: NSimon Rettberg <simon.rettberg@rz.uni-freiburg.de> Reviewed-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo removed invalid Fixes line] Link: https://patchwork.freedesktop.org/patch/msgid/20210426161124.2b7fd708@dellnichtsogutkiste (cherry picked from commit 929b734a) Signed-off-by: NJani Nikula <jani.nikula@intel.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>
-
由 Tetsuo Handa 提交于
stable inclusion from stable-5.10.40 commit eb46907f99d633834c02d8225ad4ab31ef0b85f6 bugzilla: 51882 CVE: NA -------------------------------- commit ffb324e6 upstream. syzbot is reporting OOB write at vga16fb_imageblit() [1], for resize_screen() from ioctl(VT_RESIZE) returns 0 without checking whether requested rows/columns fit the amount of memory reserved for the graphical screen if current mode is KD_GRAPHICS. ---------- #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/ioctl.h> #include <linux/kd.h> #include <linux/vt.h> int main(int argc, char *argv[]) { const int fd = open("/dev/char/4:1", O_RDWR); struct vt_sizes vt = { 0x4100, 2 }; ioctl(fd, KDSETMODE, KD_GRAPHICS); ioctl(fd, VT_RESIZE, &vt); ioctl(fd, KDSETMODE, KD_TEXT); return 0; } ---------- Allow framebuffer drivers to return -EINVAL, by moving vc->vc_mode != KD_GRAPHICS check from resize_screen() to fbcon_resize(). Link: https://syzkaller.appspot.com/bug?extid=1f29e126cf461c4de3b3 [1] Reported-by: Nsyzbot <syzbot+1f29e126cf461c4de3b3@syzkaller.appspotmail.com> Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: Nsyzbot <syzbot+1f29e126cf461c4de3b3@syzkaller.appspotmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.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>
-
由 Maciej W. Rozycki 提交于
stable inclusion from stable-5.10.40 commit a14ca25d4f2310f4b95b8f095135a69fdefb8261 bugzilla: 51882 CVE: NA -------------------------------- commit 860dafa9 upstream. Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763 ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3Signed-off-by: NMaciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.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>
-
由 Maciej W. Rozycki 提交于
stable inclusion from stable-5.10.40 commit 8026eb8242bcc3fa54a068050a6dbb5769226122 bugzilla: 51882 CVE: NA -------------------------------- commit a90c275e upstream. Revert the removal of code handling extra VT_RESIZEX ioctl's parameters beyond those that VT_RESIZE supports, fixing a functional regression causing `svgatextmode' not to resize the VT anymore. As a consequence of the reverted change when the video adapter is reprogrammed from the original say 80x25 text mode using a 9x16 character cell (720x400 pixel resolution) to say 80x37 text mode and the same character cell (720x592 pixel resolution), the VT geometry does not get updated and only upper two thirds of the screen are used for the VT, and the lower part remains blank. The proportions change according to text mode geometries chosen. Revert the change verbatim then, bringing back previous VT resizing. Signed-off-by: NMaciej W. Rozycki <macro@orcam.me.uk> Fixes: 988d0763 ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.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>
-
由 Maciej W. Rozycki 提交于
stable inclusion from stable-5.10.40 commit a3de46844f343d884efa42b505d8350143447d77 bugzilla: 51882 CVE: NA -------------------------------- commit d4d0ad57 upstream. Fix an issue with VGA console font size changes made after the initial video text mode has been changed with a user tool like `svgatextmode' calling the VT_RESIZEX ioctl. As it stands in that case the original screen geometry continues being used to validate further VT resizing. Consequently when the video adapter is firstly reprogrammed from the original say 80x25 text mode using a 9x16 character cell (720x400 pixel resolution) to say 80x37 text mode and the same character cell (720x592 pixel resolution), and secondly the CRTC character cell updated to 9x8 (by loading a suitable font with the KD_FONT_OP_SET request of the KDFONTOP ioctl), the VT geometry does not get further updated from 80x37 and only upper half of the screen is used for the VT, with the lower half showing rubbish corresponding to whatever happens to be there in the video memory that maps to that part of the screen. Of course the proportions change according to text mode geometries and font sizes chosen. Address the problem then, by updating the text mode geometry defaults rather than checking against them whenever the VT is resized via a user ioctl. Signed-off-by: NMaciej W. Rozycki <macro@orcam.me.uk> Fixes: e400b6ec ("vt/vgacon: Check if screen resize request comes from userspace") Cc: stable@vger.kernel.org # v2.6.24+ Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.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>
-
stable inclusion from stable-5.10.40 commit 8e0d302e7e518cf6260db991aaee17da65fb25cf bugzilla: 51882 CVE: NA -------------------------------- commit dc13cac4 upstream. The return of ioremap if not checked, and can lead to a NULL to be assigned to hga_vram. Potentially leading to a NULL pointer dereference. The fix adds code to deal with this case in the error label and changes how the hgafb_probe handles the return of hga_card_detect. Cc: Ferenc Bakonyi <fero@drama.obuda.kando.hu> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NIgor Matheus Andrade Torrente <igormtorrente@gmail.com> Link: https://lore.kernel.org/r/20210503115736.2104747-40-gregkh@linuxfoundation.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>
-
由 Tom Seewald 提交于
stable inclusion from stable-5.10.40 commit 98404acf0a20ca7dcbc4500d3e8d6edebd55024a bugzilla: 51882 CVE: NA -------------------------------- commit 84460f01 upstream. The function qlcnic_dl_lb_test() currently calls netdev_alloc_skb() without checking afterwards that the allocation succeeded. Fix this by checking if the skb is NULL and returning an error in such a case. Breaking out of the loop if the skb is NULL is not correct as no error would be reported to the caller and no message would be printed for the user. Cc: David S. Miller <davem@davemloft.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: NTom Seewald <tseewald@gmail.com> Link: https://lore.kernel.org/r/20210503115736.2104747-26-gregkh@linuxfoundation.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>
-
由 Phillip Potter 提交于
stable inclusion from stable-5.10.40 commit 865ec95a77f7ff3480c9a0ab1da3336c943e5846 bugzilla: 51882 CVE: NA -------------------------------- commit 6647f7a0 upstream. Check return value of lp5xx_read and if non-zero, jump to code at end of the function, causing lp5523_stop_all_engines to be executed before returning the error value up the call chain. This fixes the original commit (248b5701) which was reverted due to the University of Minnesota problems. Cc: stable <stable@vger.kernel.org> Acked-by: NJacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: NPhillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210503115736.2104747-10-gregkh@linuxfoundation.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>
-
由 Darrick J. Wong 提交于
stable inclusion from stable-5.10.40 commit 33a9ff900b9b03997aabf0dba887b11f93c2f47c bugzilla: 51882 CVE: NA -------------------------------- commit a73b6a3b upstream. In commit b05ae01f, someone tried to make the driver handle i2c read errors by simply zeroing out the register contents, but for some reason left unaltered the code that sets the cached register value the function call return value. The original patch was authored by a member of the Underhanded Mangle-happy Nerds, I'm not terribly surprised. I don't have the hardware anymore so I can't test this, but it seems like a pretty obvious API usage fix to me... Fixes: b05ae01f ("misc/ics932s401: Add a missing check to i2c_smbus_read_word_data") Signed-off-by: NDarrick J. Wong <djwong@kernel.org> Link: https://lore.kernel.org/r/20210428222534.GJ3122264@magnolia Cc: stable <stable@vger.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>
-
由 Greg Kroah-Hartman 提交于
stable inclusion from stable-5.10.40 commit e81f94a71b0070b1cdc65b619892fa53220853b8 bugzilla: 51882 CVE: NA -------------------------------- commit 30b0e0ee upstream. If alloc_workqueue() fails, properly catch this and propagate the error to the calling functions, so that the devuce initialization will properly error out. Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Bryan Brattlof <hello@bryanbrattlof.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-14-gregkh@linuxfoundation.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>
-
由 Phillip Potter 提交于
stable inclusion from stable-5.10.40 commit f9f59f4ca2d83e314b8e7ad89f76457db88cb581 bugzilla: 51882 CVE: NA -------------------------------- commit 2f4a784f upstream. Move ufshcd_set_variant call in ufs_hisi_init_common to common error section at end of the function, and then jump to this from the error checking statements for both devm_reset_control_get and ufs_hisi_get_resource. This fixes the original commit (63a06181) which was reverted due to the University of Minnesota problems. Suggested-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Avri Altman <avri.altman@wdc.com> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NPhillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210503115736.2104747-32-gregkh@linuxfoundation.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>
-
由 Anirudh Rayabharam 提交于
stable inclusion from stable-5.10.40 commit 0eb496c3c103b2dcb830aa245b69cd27f4fc70b9 bugzilla: 51882 CVE: NA -------------------------------- commit 0c32a96d upstream. In case clk_prepare() fails, capture and propagate the error code up the stack. If regulator_enable() was called earlier, properly unwind it by calling regulator_disable(). Signed-off-by: NAnirudh Rayabharam <mail@anirudhrb.com> Cc: David S. Miller <davem@davemloft.net> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-22-gregkh@linuxfoundation.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>
-
由 Du Cheng 提交于
stable inclusion from stable-5.10.40 commit c89c9a291149468b42292718047e5e891a517b97 bugzilla: 51882 CVE: NA -------------------------------- commit e6e33770 upstream. niu_pci_eeprom_read() may fail, so add checks to its return value and propagate the error up the callstack. An examination of the callstack up to niu_pci_eeprom_read shows that: niu_pci_eeprom_read() // returns int niu_pci_vpd_scan_props() // returns int niu_pci_vpd_fetch() // returns *void* niu_get_invariants() // returns int since niu_pci_vpd_fetch() returns void which breaks the bubbling up, change its return type to int so that error is propagated upwards. Signed-off-by: NDu Cheng <ducheng2@gmail.com> Cc: Shannon Nelson <shannon.lee.nelson@gmail.com> Cc: David S. Miller <davem@davemloft.net> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-24-gregkh@linuxfoundation.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>
-
由 Greg Kroah-Hartman 提交于
stable inclusion from stable-5.10.40 commit 17e22164d6c52b8c46bbf9195a6413f8d52d8a8b bugzilla: 51882 CVE: NA -------------------------------- commit 7930742d upstream. This reverts commit 26fd962b. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The change here was incorrect. While it is nice to check if niu_pci_eeprom_read() succeeded or not when using the data, any error that might have happened was not propagated upwards properly, causing the kernel to assume that these reads were successful, which results in invalid data in the buffer that was to contain the successfully read data. Cc: Kangjie Lu <kjlu@umn.edu> Cc: Shannon Nelson <shannon.lee.nelson@gmail.com> Cc: David S. Miller <davem@davemloft.net> Fixes: 26fd962b ("niu: fix missing checks of niu_pci_eeprom_read") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-23-gregkh@linuxfoundation.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>
-
由 Greg Kroah-Hartman 提交于
stable inclusion from stable-5.10.40 commit c794f7851c5d9c578e9020a3c6c166a1c340704f bugzilla: 51882 CVE: NA -------------------------------- commit b95b57df upstream. This reverts commit 5bf7295f. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. This commit does not properly detect if an error happens because the logic after this loop will not detect that there was a failed allocation. Cc: Aditya Pakki <pakki001@umn.edu> Cc: David S. Miller <davem@davemloft.net> Fixes: 5bf7295f ("qlcnic: Avoid potential NULL pointer dereference") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-25-gregkh@linuxfoundation.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>
-
由 Greg Kroah-Hartman 提交于
stable inclusion from stable-5.10.40 commit 5e4fd74089b1b1dae146016b031e483970c88642 bugzilla: 51882 CVE: NA -------------------------------- commit 68c5634c upstream. This reverts commit 76597628. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. This commit is not correct, it should not have used unlikely() and is not propagating the error properly to the calling function, so it should be reverted at this point in time. Also, if the check failed, the work queue was still assumed to be allocated, so further accesses would have continued to fail, meaning this patch does nothing to solve the root issues at all. Cc: Kangjie Lu <kjlu@umn.edu> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Bryan Brattlof <hello@bryanbrattlof.com> Fixes: 76597628 ("rtlwifi: fix a potential NULL pointer dereference") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-13-gregkh@linuxfoundation.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>
-