September 2022 - Linux-stable-mirror

+ mm-bring-back-update_mmu_cache-to-finish_fault.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: bring back update_mmu_cache() to finish_fault() has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-bring-back-update_mmu_cache-to-finish_fault.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Sergei Antonov <saproj(a)gmail.com> Subject: mm: bring back update_mmu_cache() to finish_fault() Date: Thu, 8 Sep 2022 23:48:09 +0300 Running this test program on ARMv4 a few times (sometimes just once) reproduces the bug. int main() { unsigned i; char paragon[SIZE]; void* ptr; memset(paragon, 0xAA, SIZE); ptr = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_ANON | MAP_SHARED, -1, 0); if (ptr == MAP_FAILED) return 1; printf("ptr = %p\n", ptr); for (i=0;i<10000;i++){ memset(ptr, 0xAA, SIZE); if (memcmp(ptr, paragon, SIZE)) { printf("Unexpected bytes on iteration %u!!!\n", i); break; } } munmap(ptr, SIZE); } In the "ptr" buffer there appear runs of zero bytes which are aligned by 16 and their lengths are multiple of 16. Linux v5.11 does not have the bug, "git bisect" finds the first bad commit: f9ce0be71d1f ("mm: Cleanup faultaround and finish_fault() codepaths") Before the commit update_mmu_cache() was called during a call to filemap_map_pages() as well as finish_fault(). After the commit finish_fault() lacks it. Bring back update_mmu_cache() to finish_fault() to fix the bug. Also call update_mmu_tlb() only when returning VM_FAULT_NOPAGE to more closely reproduce the code of alloc_set_pte() function that existed before the commit. On many platforms update_mmu_cache() is nop: x86, see arch/x86/include/asm/pgtable ARMv6+, see arch/arm/include/asm/tlbflush.h So, it seems, few users ran into this bug. Link: https://lkml.kernel.org/r/20220908204809.2012451-1-saproj@gmail.com Fixes: f9ce0be71d1f ("mm: Cleanup faultaround and finish_fault() codepaths") Signed-off-by: Sergei Antonov <saproj(a)gmail.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Will Deacon <will(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) --- a/mm/memory.c~mm-bring-back-update_mmu_cache-to-finish_fault +++ a/mm/memory.c @@ -4386,14 +4386,20 @@ vm_fault_t finish_fault(struct vm_fault vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address, &vmf->ptl); - ret = 0; + /* Re-check under ptl */ - if (likely(!vmf_pte_changed(vmf))) + if (likely(!vmf_pte_changed(vmf))) { do_set_pte(vmf, page, vmf->address); - else + + /* no need to invalidate: a not-present page won't be cached */ + update_mmu_cache(vma, vmf->address, vmf->pte); + + ret = 0; + } else { + update_mmu_tlb(vma, vmf->address, vmf->pte); ret = VM_FAULT_NOPAGE; + } - update_mmu_tlb(vma, vmf->address, vmf->pte); pte_unmap_unlock(vmf->pte, vmf->ptl); return ret; } _ Patches currently in -mm which might be from saproj(a)gmail.com are mm-bring-back-update_mmu_cache-to-finish_fault.patch

3 years, 3 months

1
0
0 0

+ frontswap-dont-call-init-if-no-ops-are-registered.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: frontswap: don't call ->init if no ops are registered has been added to the -mm mm-hotfixes-unstable branch. Its filename is frontswap-dont-call-init-if-no-ops-are-registered.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Christoph Hellwig <hch(a)lst.de> Subject: frontswap: don't call ->init if no ops are registered Date: Fri, 9 Sep 2022 15:08:29 +0200 If no frontswap module (i.e. zswap) was registered, frontswap_ops will be NULL. In such situation, swapon crashes with the following stack trace: Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000020a4fab000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] SMP Modules linked in: zram fsl_dpaa2_eth pcs_lynx phylink ahci_qoriq crct10dif_ce ghash_ce sbsa_gwdt fsl_mc_dpio nvme lm90 nvme_core at803x xhci_plat_hcd rtc_fsl_ftm_alarm xgmac_mdio ahci_platform i2c_imx ip6_tables ip_tables fuse Unloaded tainted modules: cppc_cpufreq():1 CPU: 10 PID: 761 Comm: swapon Not tainted 6.0.0-rc2-00454-g22100432cf14 #1 Hardware name: SolidRun Ltd. SolidRun CEX7 Platform, BIOS EDK II Jun 21 2022 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : frontswap_init+0x38/0x60 lr : __do_sys_swapon+0x8a8/0x9f4 sp : ffff80000969bcf0 x29: ffff80000969bcf0 x28: ffff37bee0d8fc00 x27: ffff80000a7f5000 x26: fffffcdefb971e80 x25: ffffaba797453b90 x24: 0000000000000064 x23: ffff37c1f209d1a8 x22: ffff37bee880e000 x21: ffffaba797748560 x20: ffff37bee0d8fce4 x19: ffffaba797748488 x18: 0000000000000014 x17: 0000000030ec029a x16: ffffaba795a479b0 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000030 x12: 0000000000000001 x11: ffff37c63c0aba18 x10: 0000000000000000 x9 : ffffaba7956b8c88 x8 : ffff80000969bcd0 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000000 x3 : ffffaba79730f000 x2 : ffff37bee0d8fc00 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: frontswap_init+0x38/0x60 __do_sys_swapon+0x8a8/0x9f4 __arm64_sys_swapon+0x28/0x3c invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0xd4/0xf4 do_el0_svc+0x38/0x4c el0_svc+0x34/0x10c el0t_64_sync_handler+0x11c/0x150 el0t_64_sync+0x190/0x194 Code: d000e283 910003fd f9006c41 f946d461 (f9400021) ---[ end trace 0000000000000000 ]--- Link: https://lkml.kernel.org/r/20220909130829.3262926-1-hch@lst.de Fixes: 1da0d94a3ec8 ("frontswap: remove support for multiple ops") Reported-by: Nathan Chancellor <nathan(a)kernel.org> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/frontswap.c | 3 +++ 1 file changed, 3 insertions(+) --- a/mm/frontswap.c~frontswap-dont-call-init-if-no-ops-are-registered +++ a/mm/frontswap.c @@ -125,6 +125,9 @@ void frontswap_init(unsigned type, unsig * p->frontswap set to something valid to work properly. */ frontswap_map_set(sis, map); + + if (!frontswap_enabled()) + return; frontswap_ops->init(type); } _ Patches currently in -mm which might be from hch(a)lst.de are frontswap-dont-call-init-if-no-ops-are-registered.patch mm-remove-the-end_write_func-argument-to-__swap_writepage.patch

3 years, 3 months

1
0
0 0

Re: [PATCH] drm/amdgpu: Don't enable LTR if not supported

by Bjorn Helgaas

On Thu, Sep 08, 2022 at 04:42:38PM +0000, Lazar, Lijo wrote: > I am not sure if ASPM settings can be generalized by PCIE core. > Performance vs Power savings when ASPM is enabled will require some > additional tuning and that will be device specific. Can you elaborate on this? In the universe of drivers, very few do their own ASPM configuration, and it's usually to work around hardware defects, e.g., L1 doesn't work on some e1000e devices, L0s doesn't work on some iwlwifi devices, etc. The core does know how to configure all the ASPM features defined in the PCIe spec, e.g., L0s, L1, L1.1, L1.2, and LTR. > In some of the other ASICs, this programming is done in VBIOS/SBIOS > firmware. Having it in driver provides the advantage of additional > tuning without forcing a VBIOS upgrade. I think it's clearly the intent of the PCIe spec that ASPM configuration be done by generic code. Here are some things that require a system-level view, not just an individual device view: - L0s, L1, and L1 Substates cannot be enabled unless both ends support it (PCIe r6.0, secs 5.4.1.4, 7.5.3.7, 5.5.4). - Devices advertise the "Acceptable Latency" they can accept for transitions from L0s or L1 to L0, and the actual latency depends on the "Exit Latencies" of all the devices in the path to the Root Port (sec 5.4.1.3.2). - LTR (required by L1.2) cannot be enabled unless it is already enabled in all upstream devices (sec 6.18). This patch relies on "ltr_path", which works now but relies on the PCI core never reconfiguring the upstream path. There might be amdgpu-specific features the driver needs to set up, but if drivers fiddle with architected features like LTR behind the PCI core's back, things are likely to break. > From: Alex Deucher <alexdeucher(a)gmail.com> > On Thu, Sep 8, 2022 at 12:12 PM Bjorn Helgaas <helgaas(a)kernel.org> wrote: > > Do you know why the driver configures ASPM itself? If the PCI core is > > doing something wrong (and I'm sure it is, ASPM support is kind of a > > mess), I'd much prefer to fix up the core where *all* drivers can > > benefit from it. > > This is the programming sequence we get from our hardware team and it > is used on both windows and Linux. As far as I understand it windows > doesn't handle this in the core, it's up to the individual drivers to > enable it. I'm not familiar with how this should be enabled > generically, but at least for our hardware, it seems to have some > variation compared to what is done in the PCI core due to stability, > etc. It seems to me that this may need asic specific implementations > for a lot of hardware depending on the required programming sequences. > E.g., various asics may need hardware workaround for bugs or platform > issues, etc. I can ask for more details from our hardware team. If the PCI core has stability issues, I want to fix them. This hardware may have its own stability issues, and I would ideally like to have drivers use interfaces like pci_disable_link_state() to avoid broken things. Maybe we need new interfaces for more subtle kinds of breakage. Bjorn

3 years, 3 months

3
3
0 0

[PATCH AUTOSEL 5.4 01/16] Revert "evm: Fix memleak in init_desc"

by Sasha Levin

From: Xiu Jianfeng <xiujianfeng(a)huawei.com> [ Upstream commit 51dd64bb99e4478fc5280171acd8e1b529eadaf7 ] This reverts commit ccf11dbaa07b328fa469415c362d33459c140a37. Commit ccf11dbaa07b ("evm: Fix memleak in init_desc") said there is memleak in init_desc. That may be incorrect, as we can see, tmp_tfm is saved in one of the two global variables hmac_tfm or evm_tfm[hash_algo], then if init_desc is called next time, there is no need to alloc tfm again, so in the error path of kmalloc desc or crypto_shash_init(desc), It is not a problem without freeing tmp_tfm. And also that commit did not reset the global variable to NULL after freeing tmp_tfm and this makes *tfm a dangling pointer which may cause a UAF issue. Reported-by: Guozihua (Scott) <guozihua(a)huawei.com> Signed-off-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Signed-off-by: Mimi Zohar <zohar(a)linux.ibm.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- security/integrity/evm/evm_crypto.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c index 25dac691491b..ee6bd945f3d6 100644 --- a/security/integrity/evm/evm_crypto.c +++ b/security/integrity/evm/evm_crypto.c @@ -75,7 +75,7 @@ static struct shash_desc *init_desc(char type, uint8_t hash_algo) { long rc; const char *algo; - struct crypto_shash **tfm, *tmp_tfm = NULL; + struct crypto_shash **tfm, *tmp_tfm; struct shash_desc *desc; if (type == EVM_XATTR_HMAC) { @@ -120,16 +120,13 @@ static struct shash_desc *init_desc(char type, uint8_t hash_algo) alloc: desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(*tfm), GFP_KERNEL); - if (!desc) { - crypto_free_shash(tmp_tfm); + if (!desc) return ERR_PTR(-ENOMEM); - } desc->tfm = *tfm; rc = crypto_shash_init(desc); if (rc) { - crypto_free_shash(tmp_tfm); kfree(desc); return ERR_PTR(rc); } -- 2.35.1

3 years, 3 months

3
18
0 0

FAILED: patch "[PATCH] kprobes: Prohibit probes in gate area" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 1efda38d6f9b ("kprobes: Prohibit probes in gate area") 28f6c37a2910 ("kprobes: Forbid probing on trampoline and BPF code areas") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1efda38d6f9ba26ac88b359c6277f1172db03f1e Mon Sep 17 00:00:00 2001 From: "Christian A. Ehrhardt" <lk(a)c--e.de> Date: Wed, 7 Sep 2022 22:09:17 +0200 Subject: [PATCH] kprobes: Prohibit probes in gate area The system call gate area counts as kernel text but trying to install a kprobe in this area fails with an Oops later on. To fix this explicitly disallow the gate area for kprobes. Found by syzkaller with the following reproducer: perf_event_open$cgroup(&(0x7f00000001c0)={0x6, 0x80, 0x0, 0x0, 0x0, 0x0, 0x80ffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, @perf_config_ext={0x0, 0xffffffffff600000}}, 0xffffffffffffffff, 0x0, 0xffffffffffffffff, 0x0) Sample report: BUG: unable to handle page fault for address: fffffbfff3ac6000 PGD 6dfcb067 P4D 6dfcb067 PUD 6df8f067 PMD 6de4d067 PTE 0 Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 21978 Comm: syz-executor.2 Not tainted 6.0.0-rc3-00363-g7726d4c3e60b-dirty #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:__insn_get_emulate_prefix arch/x86/lib/insn.c:91 [inline] RIP: 0010:insn_get_emulate_prefix arch/x86/lib/insn.c:106 [inline] RIP: 0010:insn_get_prefixes.part.0+0xa8/0x1110 arch/x86/lib/insn.c:134 Code: 49 be 00 00 00 00 00 fc ff df 48 8b 40 60 48 89 44 24 08 e9 81 00 00 00 e8 e5 4b 39 ff 4c 89 fa 4c 89 f9 48 c1 ea 03 83 e1 07 <42> 0f b6 14 32 38 ca 7f 08 84 d2 0f 85 06 10 00 00 48 89 d8 48 89 RSP: 0018:ffffc900088bf860 EFLAGS: 00010246 RAX: 0000000000040000 RBX: ffffffff9b9bebc0 RCX: 0000000000000000 RDX: 1ffffffff3ac6000 RSI: ffffc90002d82000 RDI: ffffc900088bf9e8 RBP: ffffffff9d630001 R08: 0000000000000000 R09: ffffc900088bf9e8 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffffffff9d630000 R14: dffffc0000000000 R15: ffffffff9d630000 FS: 00007f63eef63640(0000) GS:ffff88806d000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff3ac6000 CR3: 0000000029d90005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> insn_get_prefixes arch/x86/lib/insn.c:131 [inline] insn_get_opcode arch/x86/lib/insn.c:272 [inline] insn_get_modrm+0x64a/0x7b0 arch/x86/lib/insn.c:343 insn_get_sib+0x29a/0x330 arch/x86/lib/insn.c:421 insn_get_displacement+0x350/0x6b0 arch/x86/lib/insn.c:464 insn_get_immediate arch/x86/lib/insn.c:632 [inline] insn_get_length arch/x86/lib/insn.c:707 [inline] insn_decode+0x43a/0x490 arch/x86/lib/insn.c:747 can_probe+0xfc/0x1d0 arch/x86/kernel/kprobes/core.c:282 arch_prepare_kprobe+0x79/0x1c0 arch/x86/kernel/kprobes/core.c:739 prepare_kprobe kernel/kprobes.c:1160 [inline] register_kprobe kernel/kprobes.c:1641 [inline] register_kprobe+0xb6e/0x1690 kernel/kprobes.c:1603 __register_trace_kprobe kernel/trace/trace_kprobe.c:509 [inline] __register_trace_kprobe+0x26a/0x2d0 kernel/trace/trace_kprobe.c:477 create_local_trace_kprobe+0x1f7/0x350 kernel/trace/trace_kprobe.c:1833 perf_kprobe_init+0x18c/0x280 kernel/trace/trace_event_perf.c:271 perf_kprobe_event_init+0xf8/0x1c0 kernel/events/core.c:9888 perf_try_init_event+0x12d/0x570 kernel/events/core.c:11261 perf_init_event kernel/events/core.c:11325 [inline] perf_event_alloc.part.0+0xf7f/0x36a0 kernel/events/core.c:11619 perf_event_alloc kernel/events/core.c:12059 [inline] __do_sys_perf_event_open+0x4a8/0x2a00 kernel/events/core.c:12157 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f63ef7efaed Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f63eef63028 EFLAGS: 00000246 ORIG_RAX: 000000000000012a RAX: ffffffffffffffda RBX: 00007f63ef90ff80 RCX: 00007f63ef7efaed RDX: 0000000000000000 RSI: ffffffffffffffff RDI: 00000000200001c0 RBP: 00007f63ef86019c R08: 0000000000000000 R09: 0000000000000000 R10: ffffffffffffffff R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000002 R14: 00007f63ef90ff80 R15: 00007f63eef43000 </TASK> Modules linked in: CR2: fffffbfff3ac6000 ---[ end trace 0000000000000000 ]--- RIP: 0010:__insn_get_emulate_prefix arch/x86/lib/insn.c:91 [inline] RIP: 0010:insn_get_emulate_prefix arch/x86/lib/insn.c:106 [inline] RIP: 0010:insn_get_prefixes.part.0+0xa8/0x1110 arch/x86/lib/insn.c:134 Code: 49 be 00 00 00 00 00 fc ff df 48 8b 40 60 48 89 44 24 08 e9 81 00 00 00 e8 e5 4b 39 ff 4c 89 fa 4c 89 f9 48 c1 ea 03 83 e1 07 <42> 0f b6 14 32 38 ca 7f 08 84 d2 0f 85 06 10 00 00 48 89 d8 48 89 RSP: 0018:ffffc900088bf860 EFLAGS: 00010246 RAX: 0000000000040000 RBX: ffffffff9b9bebc0 RCX: 0000000000000000 RDX: 1ffffffff3ac6000 RSI: ffffc90002d82000 RDI: ffffc900088bf9e8 RBP: ffffffff9d630001 R08: 0000000000000000 R09: ffffc900088bf9e8 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffffffff9d630000 R14: dffffc0000000000 R15: ffffffff9d630000 FS: 00007f63eef63640(0000) GS:ffff88806d000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff3ac6000 CR3: 0000000029d90005 CR4: 0000000000770ef0 PKRU: 55555554 ================================================================== Link: https://lkml.kernel.org/r/20220907200917.654103-1-lk@c--e.de cc: "Naveen N. Rao" <naveen.n.rao(a)linux.ibm.com> cc: Anil S Keshavamurthy <anil.s.keshavamurthy(a)intel.com> cc: "David S. Miller" <davem(a)davemloft.net> Cc: stable(a)vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Acked-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Signed-off-by: Christian A. Ehrhardt <lk(a)c--e.de> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 08350e35aba2..ca9d834d0b84 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1562,6 +1562,7 @@ static int check_kprobe_address_safe(struct kprobe *p, /* Ensure it is not in reserved area nor out of text */ if (!(core_kernel_text((unsigned long) p->addr) || is_module_text_address((unsigned long) p->addr)) || + in_gate_area_no_mm((unsigned long) p->addr) || within_kprobe_blacklist((unsigned long) p->addr) || jump_label_text_reserved(p->addr, p->addr) || static_call_text_reserved(p->addr, p->addr) ||

3 years, 3 months

1
0
0 0

FAILED: patch "[PATCH] vfio/type1: Unpin zero pages" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 873aefb376bb ("vfio/type1: Unpin zero pages") 4b6c33b32296 ("vfio/type1: Prepare for batched pinning with struct vfio_batch") be16c1fd99f4 ("vfio/type1: Change success value of vaddr_get_pfn()") aae7a75a821a ("vfio/type1: Add proper error unwind for vfio_iommu_replay()") 64019a2e467a ("mm/gup: remove task_struct pointer for all gup code") bce617edecad ("mm: do page fault accounting in handle_mm_fault") ed03d924587e ("mm/gup: use a standard migration target allocation callback") bbe88753bd42 ("mm/hugetlb: make hugetlb migration callback CMA aware") 41b4dc14ee80 ("mm/gup: restrict CMA region by using allocation scope API") 19fc7bed252c ("mm/migrate: introduce a standard migration target allocation function") d92bbc2719bd ("mm/hugetlb: unify migration callbacks") b4b382238ed2 ("mm/migrate: move migration helper from .h to .c") c7073bab5772 ("mm/page_isolation: prefer the node of the source page") 3e4e28c5a8f0 ("mmap locking API: convert mmap_sem API comments") d8ed45c5dcd4 ("mmap locking API: use coccinelle to convert mmap_sem rwsem call sites") ca5999fde0a1 ("mm: introduce include/linux/pgtable.h") 420c2091b65a ("mm/gup: introduce pin_user_pages_locked()") 5a36f0f3f518 ("Merge tag 'vfio-v5.8-rc1' of git://github.com/awilliam/linux-vfio") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 873aefb376bbc0ed1dd2381ea1d6ec88106fdbd4 Mon Sep 17 00:00:00 2001 From: Alex Williamson <alex.williamson(a)redhat.com> Date: Mon, 29 Aug 2022 21:05:40 -0600 Subject: [PATCH] vfio/type1: Unpin zero pages There's currently a reference count leak on the zero page. We increment the reference via pin_user_pages_remote(), but the page is later handled as an invalid/reserved page, therefore it's not accounted against the user and not unpinned by our put_pfn(). Introducing special zero page handling in put_pfn() would resolve the leak, but without accounting of the zero page, a single user could still create enough mappings to generate a reference count overflow. The zero page is always resident, so for our purposes there's no reason to keep it pinned. Therefore, add a loop to walk pages returned from pin_user_pages_remote() and unpin any zero pages. Cc: stable(a)vger.kernel.org Reported-by: Luboslav Pivarc <lpivarc(a)redhat.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Link: https://lore.kernel.org/r/166182871735.3518559.8884121293045337358.stgit@om… Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c index db516c90a977..8706482665d1 100644 --- a/drivers/vfio/vfio_iommu_type1.c +++ b/drivers/vfio/vfio_iommu_type1.c @@ -558,6 +558,18 @@ static int vaddr_get_pfns(struct mm_struct *mm, unsigned long vaddr, ret = pin_user_pages_remote(mm, vaddr, npages, flags | FOLL_LONGTERM, pages, NULL, NULL); if (ret > 0) { + int i; + + /* + * The zero page is always resident, we don't need to pin it + * and it falls into our invalid/reserved test so we don't + * unpin in put_pfn(). Unpin all zero pages in the batch here. + */ + for (i = 0 ; i < ret; i++) { + if (unlikely(is_zero_pfn(page_to_pfn(pages[i])))) + unpin_user_page(pages[i]); + } + *pfn = page_to_pfn(pages[0]); goto done; }

3 years, 3 months

1
0
0 0

FAILED: patch "[PATCH] vfio/type1: Unpin zero pages" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 873aefb376bb ("vfio/type1: Unpin zero pages") 4b6c33b32296 ("vfio/type1: Prepare for batched pinning with struct vfio_batch") be16c1fd99f4 ("vfio/type1: Change success value of vaddr_get_pfn()") aae7a75a821a ("vfio/type1: Add proper error unwind for vfio_iommu_replay()") 64019a2e467a ("mm/gup: remove task_struct pointer for all gup code") bce617edecad ("mm: do page fault accounting in handle_mm_fault") ed03d924587e ("mm/gup: use a standard migration target allocation callback") bbe88753bd42 ("mm/hugetlb: make hugetlb migration callback CMA aware") 41b4dc14ee80 ("mm/gup: restrict CMA region by using allocation scope API") 19fc7bed252c ("mm/migrate: introduce a standard migration target allocation function") d92bbc2719bd ("mm/hugetlb: unify migration callbacks") b4b382238ed2 ("mm/migrate: move migration helper from .h to .c") c7073bab5772 ("mm/page_isolation: prefer the node of the source page") 3e4e28c5a8f0 ("mmap locking API: convert mmap_sem API comments") d8ed45c5dcd4 ("mmap locking API: use coccinelle to convert mmap_sem rwsem call sites") ca5999fde0a1 ("mm: introduce include/linux/pgtable.h") 420c2091b65a ("mm/gup: introduce pin_user_pages_locked()") 5a36f0f3f518 ("Merge tag 'vfio-v5.8-rc1' of git://github.com/awilliam/linux-vfio") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 873aefb376bbc0ed1dd2381ea1d6ec88106fdbd4 Mon Sep 17 00:00:00 2001 From: Alex Williamson <alex.williamson(a)redhat.com> Date: Mon, 29 Aug 2022 21:05:40 -0600 Subject: [PATCH] vfio/type1: Unpin zero pages There's currently a reference count leak on the zero page. We increment the reference via pin_user_pages_remote(), but the page is later handled as an invalid/reserved page, therefore it's not accounted against the user and not unpinned by our put_pfn(). Introducing special zero page handling in put_pfn() would resolve the leak, but without accounting of the zero page, a single user could still create enough mappings to generate a reference count overflow. The zero page is always resident, so for our purposes there's no reason to keep it pinned. Therefore, add a loop to walk pages returned from pin_user_pages_remote() and unpin any zero pages. Cc: stable(a)vger.kernel.org Reported-by: Luboslav Pivarc <lpivarc(a)redhat.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Link: https://lore.kernel.org/r/166182871735.3518559.8884121293045337358.stgit@om… Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c index db516c90a977..8706482665d1 100644 --- a/drivers/vfio/vfio_iommu_type1.c +++ b/drivers/vfio/vfio_iommu_type1.c @@ -558,6 +558,18 @@ static int vaddr_get_pfns(struct mm_struct *mm, unsigned long vaddr, ret = pin_user_pages_remote(mm, vaddr, npages, flags | FOLL_LONGTERM, pages, NULL, NULL); if (ret > 0) { + int i; + + /* + * The zero page is always resident, we don't need to pin it + * and it falls into our invalid/reserved test so we don't + * unpin in put_pfn(). Unpin all zero pages in the batch here. + */ + for (i = 0 ; i < ret; i++) { + if (unlikely(is_zero_pfn(page_to_pfn(pages[i])))) + unpin_user_page(pages[i]); + } + *pfn = page_to_pfn(pages[0]); goto done; }

3 years, 3 months

1
0
0 0

FAILED: patch "[PATCH] vfio/type1: Unpin zero pages" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 873aefb376bb ("vfio/type1: Unpin zero pages") 4b6c33b32296 ("vfio/type1: Prepare for batched pinning with struct vfio_batch") be16c1fd99f4 ("vfio/type1: Change success value of vaddr_get_pfn()") aae7a75a821a ("vfio/type1: Add proper error unwind for vfio_iommu_replay()") 64019a2e467a ("mm/gup: remove task_struct pointer for all gup code") bce617edecad ("mm: do page fault accounting in handle_mm_fault") ed03d924587e ("mm/gup: use a standard migration target allocation callback") bbe88753bd42 ("mm/hugetlb: make hugetlb migration callback CMA aware") 41b4dc14ee80 ("mm/gup: restrict CMA region by using allocation scope API") 19fc7bed252c ("mm/migrate: introduce a standard migration target allocation function") d92bbc2719bd ("mm/hugetlb: unify migration callbacks") b4b382238ed2 ("mm/migrate: move migration helper from .h to .c") c7073bab5772 ("mm/page_isolation: prefer the node of the source page") 3e4e28c5a8f0 ("mmap locking API: convert mmap_sem API comments") d8ed45c5dcd4 ("mmap locking API: use coccinelle to convert mmap_sem rwsem call sites") ca5999fde0a1 ("mm: introduce include/linux/pgtable.h") 420c2091b65a ("mm/gup: introduce pin_user_pages_locked()") 5a36f0f3f518 ("Merge tag 'vfio-v5.8-rc1' of git://github.com/awilliam/linux-vfio") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 873aefb376bbc0ed1dd2381ea1d6ec88106fdbd4 Mon Sep 17 00:00:00 2001 From: Alex Williamson <alex.williamson(a)redhat.com> Date: Mon, 29 Aug 2022 21:05:40 -0600 Subject: [PATCH] vfio/type1: Unpin zero pages There's currently a reference count leak on the zero page. We increment the reference via pin_user_pages_remote(), but the page is later handled as an invalid/reserved page, therefore it's not accounted against the user and not unpinned by our put_pfn(). Introducing special zero page handling in put_pfn() would resolve the leak, but without accounting of the zero page, a single user could still create enough mappings to generate a reference count overflow. The zero page is always resident, so for our purposes there's no reason to keep it pinned. Therefore, add a loop to walk pages returned from pin_user_pages_remote() and unpin any zero pages. Cc: stable(a)vger.kernel.org Reported-by: Luboslav Pivarc <lpivarc(a)redhat.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Link: https://lore.kernel.org/r/166182871735.3518559.8884121293045337358.stgit@om… Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c index db516c90a977..8706482665d1 100644 --- a/drivers/vfio/vfio_iommu_type1.c +++ b/drivers/vfio/vfio_iommu_type1.c @@ -558,6 +558,18 @@ static int vaddr_get_pfns(struct mm_struct *mm, unsigned long vaddr, ret = pin_user_pages_remote(mm, vaddr, npages, flags | FOLL_LONGTERM, pages, NULL, NULL); if (ret > 0) { + int i; + + /* + * The zero page is always resident, we don't need to pin it + * and it falls into our invalid/reserved test so we don't + * unpin in put_pfn(). Unpin all zero pages in the batch here. + */ + for (i = 0 ; i < ret; i++) { + if (unlikely(is_zero_pfn(page_to_pfn(pages[i])))) + unpin_user_page(pages[i]); + } + *pfn = page_to_pfn(pages[0]); goto done; }

3 years, 3 months

1
0
0 0

FAILED: patch "[PATCH] vfio/type1: Unpin zero pages" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 873aefb376bb ("vfio/type1: Unpin zero pages") 4b6c33b32296 ("vfio/type1: Prepare for batched pinning with struct vfio_batch") be16c1fd99f4 ("vfio/type1: Change success value of vaddr_get_pfn()") aae7a75a821a ("vfio/type1: Add proper error unwind for vfio_iommu_replay()") 64019a2e467a ("mm/gup: remove task_struct pointer for all gup code") bce617edecad ("mm: do page fault accounting in handle_mm_fault") ed03d924587e ("mm/gup: use a standard migration target allocation callback") bbe88753bd42 ("mm/hugetlb: make hugetlb migration callback CMA aware") 41b4dc14ee80 ("mm/gup: restrict CMA region by using allocation scope API") 19fc7bed252c ("mm/migrate: introduce a standard migration target allocation function") d92bbc2719bd ("mm/hugetlb: unify migration callbacks") b4b382238ed2 ("mm/migrate: move migration helper from .h to .c") c7073bab5772 ("mm/page_isolation: prefer the node of the source page") 3e4e28c5a8f0 ("mmap locking API: convert mmap_sem API comments") d8ed45c5dcd4 ("mmap locking API: use coccinelle to convert mmap_sem rwsem call sites") ca5999fde0a1 ("mm: introduce include/linux/pgtable.h") 420c2091b65a ("mm/gup: introduce pin_user_pages_locked()") 5a36f0f3f518 ("Merge tag 'vfio-v5.8-rc1' of git://github.com/awilliam/linux-vfio") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 873aefb376bbc0ed1dd2381ea1d6ec88106fdbd4 Mon Sep 17 00:00:00 2001 From: Alex Williamson <alex.williamson(a)redhat.com> Date: Mon, 29 Aug 2022 21:05:40 -0600 Subject: [PATCH] vfio/type1: Unpin zero pages There's currently a reference count leak on the zero page. We increment the reference via pin_user_pages_remote(), but the page is later handled as an invalid/reserved page, therefore it's not accounted against the user and not unpinned by our put_pfn(). Introducing special zero page handling in put_pfn() would resolve the leak, but without accounting of the zero page, a single user could still create enough mappings to generate a reference count overflow. The zero page is always resident, so for our purposes there's no reason to keep it pinned. Therefore, add a loop to walk pages returned from pin_user_pages_remote() and unpin any zero pages. Cc: stable(a)vger.kernel.org Reported-by: Luboslav Pivarc <lpivarc(a)redhat.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Link: https://lore.kernel.org/r/166182871735.3518559.8884121293045337358.stgit@om… Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c index db516c90a977..8706482665d1 100644 --- a/drivers/vfio/vfio_iommu_type1.c +++ b/drivers/vfio/vfio_iommu_type1.c @@ -558,6 +558,18 @@ static int vaddr_get_pfns(struct mm_struct *mm, unsigned long vaddr, ret = pin_user_pages_remote(mm, vaddr, npages, flags | FOLL_LONGTERM, pages, NULL, NULL); if (ret > 0) { + int i; + + /* + * The zero page is always resident, we don't need to pin it + * and it falls into our invalid/reserved test so we don't + * unpin in put_pfn(). Unpin all zero pages in the batch here. + */ + for (i = 0 ; i < ret; i++) { + if (unlikely(is_zero_pfn(page_to_pfn(pages[i])))) + unpin_user_page(pages[i]); + } + *pfn = page_to_pfn(pages[0]); goto done; }

3 years, 3 months

1
0
0 0

FAILED: patch "[PATCH] vfio/type1: Unpin zero pages" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 873aefb376bb ("vfio/type1: Unpin zero pages") 4b6c33b32296 ("vfio/type1: Prepare for batched pinning with struct vfio_batch") be16c1fd99f4 ("vfio/type1: Change success value of vaddr_get_pfn()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 873aefb376bbc0ed1dd2381ea1d6ec88106fdbd4 Mon Sep 17 00:00:00 2001 From: Alex Williamson <alex.williamson(a)redhat.com> Date: Mon, 29 Aug 2022 21:05:40 -0600 Subject: [PATCH] vfio/type1: Unpin zero pages There's currently a reference count leak on the zero page. We increment the reference via pin_user_pages_remote(), but the page is later handled as an invalid/reserved page, therefore it's not accounted against the user and not unpinned by our put_pfn(). Introducing special zero page handling in put_pfn() would resolve the leak, but without accounting of the zero page, a single user could still create enough mappings to generate a reference count overflow. The zero page is always resident, so for our purposes there's no reason to keep it pinned. Therefore, add a loop to walk pages returned from pin_user_pages_remote() and unpin any zero pages. Cc: stable(a)vger.kernel.org Reported-by: Luboslav Pivarc <lpivarc(a)redhat.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Link: https://lore.kernel.org/r/166182871735.3518559.8884121293045337358.stgit@om… Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c index db516c90a977..8706482665d1 100644 --- a/drivers/vfio/vfio_iommu_type1.c +++ b/drivers/vfio/vfio_iommu_type1.c @@ -558,6 +558,18 @@ static int vaddr_get_pfns(struct mm_struct *mm, unsigned long vaddr, ret = pin_user_pages_remote(mm, vaddr, npages, flags | FOLL_LONGTERM, pages, NULL, NULL); if (ret > 0) { + int i; + + /* + * The zero page is always resident, we don't need to pin it + * and it falls into our invalid/reserved test so we don't + * unpin in put_pfn(). Unpin all zero pages in the batch here. + */ + for (i = 0 ; i < ret; i++) { + if (unlikely(is_zero_pfn(page_to_pfn(pages[i])))) + unpin_user_page(pages[i]); + } + *pfn = page_to_pfn(pages[0]); goto done; }

3 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2022