April 2022 - Linux-stable-mirror

[merged] lz4-fix-lz4_decompress_safe_partial-read-out-of-bound.patch removed from -mm tree

by Andrew Morton

The patch titled Subject: lz4: fix LZ4_decompress_safe_partial read out of bound has been removed from the -mm tree. Its filename was lz4-fix-lz4_decompress_safe_partial-read-out-of-bound.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Guo Xuenan <guoxuenan(a)huawei.com> Subject: lz4: fix LZ4_decompress_safe_partial read out of bound When partialDecoding, it is EOF if we've either filled the output buffer or can't proceed with reading an offset for following match. In some extreme corner cases when compressed data is suitably corrupted, UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial may lead to read out of bound problem during decoding. lz4 upstream has fixed it [2] and this issue has been disscussed here [3] before. current decompression routine was ported from lz4 v1.8.3, bumping lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd better fix it first. [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/ Link: https://lkml.kernel.org/r/20211111105048.2006070-1-guoxuenan@huawei.com Reported-by: syzbot+63d688f1d899c588fb71(a)syzkaller.appspotmail.com Signed-off-by: Guo Xuenan <guoxuenan(a)huawei.com> Reviewed-by: Nick Terrell <terrelln(a)fb.com> Acked-by: Gao Xiang <hsiangkao(a)linux.alibaba.com> Cc: Yann Collet <cyan(a)fb.com> Cc: Chengyang Fan <cy.fan(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/lz4/lz4_decompress.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/lib/lz4/lz4_decompress.c~lz4-fix-lz4_decompress_safe_partial-read-out-of-bound +++ a/lib/lz4/lz4_decompress.c @@ -271,8 +271,12 @@ static FORCE_INLINE int LZ4_decompress_g ip += length; op += length; - /* Necessarily EOF, due to parsing restrictions */ - if (!partialDecoding || (cpy == oend)) + /* Necessarily EOF when !partialDecoding. + * When partialDecoding, it is EOF if we've either + * filled the output buffer or + * can't proceed with reading an offset for following match. + */ + if (!partialDecoding || (cpy == oend) || (ip >= (iend - 2))) break; } else { /* may overwrite up to WILDCOPYLENGTH beyond cpy */ _ Patches currently in -mm which might be from guoxuenan(a)huawei.com are

2 years, 9 months

1
0
0 0

[merged] highmem-fix-checks-in-__kmap_local_sched_inout.patch removed from -mm tree

by Andrew Morton

The patch titled Subject: highmem: fix checks in __kmap_local_sched_{in,out} has been removed from the -mm tree. Its filename was highmem-fix-checks-in-__kmap_local_sched_inout.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Max Filippov <jcmvbkbc(a)gmail.com> Subject: highmem: fix checks in __kmap_local_sched_{in,out} When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} check that even slots in the tsk->kmap_ctrl.pteval are unmapped. The slots are initialized with 0 value, but the check is done with pte_none. 0 pte however does not necessarily mean that pte_none will return true. e.g. on xtensa it returns false, resulting in the following runtime warnings: WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108 CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_out+0x51/0x108 __schedule+0x71a/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0 CPU: 0 PID: 101 Comm: touch Tainted: G W 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_in+0x50/0xe0 finish_task_switch$isra$0+0x1ce/0x2f8 __schedule+0x86e/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f Fix it by replacing !pte_none(pteval) with pte_val(pteval) != 0. Link: https://lkml.kernel.org/r/20220403235159.3498065-1-jcmvbkbc@gmail.com Fixes: 5fbda3ecd14a ("sched: highmem: Store local kmaps in task struct") Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com> Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: "Peter Zijlstra (Intel)" <peterz(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/highmem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/mm/highmem.c~highmem-fix-checks-in-__kmap_local_sched_inout +++ a/mm/highmem.c @@ -624,7 +624,7 @@ void __kmap_local_sched_out(void) /* With debug all even slots are unmapped and act as guard */ if (IS_ENABLED(CONFIG_DEBUG_KMAP_LOCAL) && !(i & 0x01)) { - WARN_ON_ONCE(!pte_none(pteval)); + WARN_ON_ONCE(pte_val(pteval) != 0); continue; } if (WARN_ON_ONCE(pte_none(pteval))) @@ -661,7 +661,7 @@ void __kmap_local_sched_in(void) /* With debug all even slots are unmapped and act as guard */ if (IS_ENABLED(CONFIG_DEBUG_KMAP_LOCAL) && !(i & 0x01)) { - WARN_ON_ONCE(!pte_none(pteval)); + WARN_ON_ONCE(pte_val(pteval) != 0); continue; } if (WARN_ON_ONCE(pte_none(pteval))) _ Patches currently in -mm which might be from jcmvbkbc(a)gmail.com are

2 years, 9 months

1
0
0 0

[PATCH for STABLE] rtc: mc146818-lib: fix RTC presence check

by Mateusz Jończyk

commit ea6fa4961aab8f90a8aa03575a98b4bda368d4b6 upstream. Please apply to 5.15 and 5.16 trees. To prevent an infinite loop in mc146818_get_time(), commit 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs") added a check for RTC availability. Together with a later fix, it checked if bit 6 in register 0x0d is cleared. This, however, caused a false negative on a motherboard with an AMD SB710 southbridge; according to the specification [1], bit 6 of register 0x0d of this chipset is a scratchbit. This caused a regression in Linux 5.11 - the RTC was determined broken by the kernel and not used by rtc-cmos.c [3]. This problem was also reported in Fedora [4]. As a better alternative, check whether the UIP ("Update-in-progress") bit is set for longer then 10ms. If that is the case, then apparently the RTC is either absent (and all register reads return 0xff) or broken. Also limit the number of loop iterations in mc146818_get_time() to 10 to prevent an infinite loop there. An equivalent patch has been in mainline since 5.17-rc1 and I have received no complaints (the patch was refactored by following patches in my mainline series, but the algorithm remained). Also, Google searches for appropriate error messages are giving no problem reports. Additionally, a more strigent test introduced by commit 2aaa36e95ea5 ("selftests/rtc: continuously read RTC in a loop for 30s") was added in merge window for kernel 5.18 and I have received no reports it was failing. Changes from the upstream commit: - return values from mc146818_get_time() are different then in mainline, so return a different value in case there is an error. - print a warning in mc146818_get_time() if the RTC read fails. In the mainline patch series this was done by callers of mc146818_get_time(), for simplicity do this in mc146818_get_time() here. [1] AMD SB700/710/750 Register Reference Guide, page 308, https://developer.amd.com/wordpress/media/2012/10/43009_sb7xx_rrg_pub_1.00.… [2] 7th Generation Intel ® Processor Family I/O for U/Y Platforms [...] Datasheet Volume 1 of 2, page 209 Intel's Document Number: 334658-006, https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7th… [3] Functions in arch/x86/kernel/rtc.c apparently were using it. [4] https://bugzilla.redhat.com/show_bug.cgi?id=1936688 Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs") Fixes: ebb22a059436 ("rtc: mc146818: Dont test for bit 0-5 in Register D") Signed-off-by: Mateusz Jończyk <mat.jonczyk(a)o2.pl> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Alessandro Zummo <a.zummo(a)towertech.it> Cc: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Link: https://lore.kernel.org/r/20211210200131.153887-5-mat.jonczyk@o2.pl --- Tested on 3 computers and 2 different VMs (amd64 and i386), both on kernel 5.15 and 5.16 stable releases. Then changed pr_err() to pr_err_ratelimited(), but did not retest so carefully. drivers/rtc/rtc-cmos.c | 10 ++++------ drivers/rtc/rtc-mc146818-lib.c | 35 ++++++++++++++++++++++++++++++---- include/linux/mc146818rtc.h | 1 + 3 files changed, 36 insertions(+), 10 deletions(-) diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c index dc3f8b0dde98..9404f58ee01d 100644 --- a/drivers/rtc/rtc-cmos.c +++ b/drivers/rtc/rtc-cmos.c @@ -793,16 +793,14 @@ cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq) rename_region(ports, dev_name(&cmos_rtc.rtc->dev)); - spin_lock_irq(&rtc_lock); - - /* Ensure that the RTC is accessible. Bit 6 must be 0! */ - if ((CMOS_READ(RTC_VALID) & 0x40) != 0) { - spin_unlock_irq(&rtc_lock); - dev_warn(dev, "not accessible\n"); + if (!mc146818_does_rtc_work()) { + dev_warn(dev, "broken or not accessible\n"); retval = -ENXIO; goto cleanup1; } + spin_lock_irq(&rtc_lock); + if (!(flags & CMOS_RTC_FLAGS_NOFREQ)) { /* force periodic irq to CMOS reset default of 1024Hz; * diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c index 04b05e3b68cb..f58b0d9dacca 100644 --- a/drivers/rtc/rtc-mc146818-lib.c +++ b/drivers/rtc/rtc-mc146818-lib.c @@ -8,10 +8,36 @@ #include <linux/acpi.h> #endif +/* + * If the UIP (Update-in-progress) bit of the RTC is set for more then + * 10ms, the RTC is apparently broken or not present. + */ +bool mc146818_does_rtc_work(void) +{ + int i; + unsigned char val; + unsigned long flags; + + for (i = 0; i < 10; i++) { + spin_lock_irqsave(&rtc_lock, flags); + val = CMOS_READ(RTC_FREQ_SELECT); + spin_unlock_irqrestore(&rtc_lock, flags); + + if ((val & RTC_UIP) == 0) + return true; + + mdelay(1); + } + + return false; +} +EXPORT_SYMBOL_GPL(mc146818_does_rtc_work); + unsigned int mc146818_get_time(struct rtc_time *time) { unsigned char ctrl; unsigned long flags; + unsigned int iter_count = 0; unsigned char century = 0; bool retry; @@ -20,13 +46,14 @@ unsigned int mc146818_get_time(struct rtc_time *time) #endif again: - spin_lock_irqsave(&rtc_lock, flags); - /* Ensure that the RTC is accessible. Bit 6 must be 0! */ - if (WARN_ON_ONCE((CMOS_READ(RTC_VALID) & 0x40) != 0)) { - spin_unlock_irqrestore(&rtc_lock, flags); + if (iter_count > 10) { + pr_err_ratelimited("Unable to read current time from RTC\n"); memset(time, 0xff, sizeof(*time)); return 0; } + iter_count++; + + spin_lock_irqsave(&rtc_lock, flags); /* * Check whether there is an update in progress during which the diff --git a/include/linux/mc146818rtc.h b/include/linux/mc146818rtc.h index 0661af17a758..69c80c4325bf 100644 --- a/include/linux/mc146818rtc.h +++ b/include/linux/mc146818rtc.h @@ -123,6 +123,7 @@ struct cmos_rtc_board_info { #define RTC_IO_EXTENT_USED RTC_IO_EXTENT #endif /* ARCH_RTC_LOCATION */ +bool mc146818_does_rtc_work(void); unsigned int mc146818_get_time(struct rtc_time *time); int mc146818_set_time(struct rtc_time *time); base-commit: 06f50ca83ace219cb72213369d2be05bb0dd337e -- 2.25.1

2 years, 9 months

2
1
0 0

stable 5.10: please revert c4dc584a2d4c8d74b054f09d67e0a076767bdee5

by Randy Dunlap

According to https://bugzilla.kernel.org/show_bug.cgi?id=215823, c4dc584a2d4c8d74b054f09d67e0a076767bdee5 ("hv: utils: add PTP_1588_CLOCK to Kconfig to fix build") is a problem for 5.10 since CONFIG_PTP_1588_CLOCK_OPTIONAL does not exist in 5.10. This prevents the hyper-V NIC timestamping from working, so please revert that commit. -- ~Randy

2 years, 9 months

2
1
0 0

[PATCH 1/1] iommu/vt-d: Calculate mask for non-aligned flushes

by Lu Baolu

From: David Stevens <stevensd(a)chromium.org> Calculate the appropriate mask for non-size-aligned page selective invalidation. Since psi uses the mask value to mask out the lower order bits of the target address, properly flushing the iotlb requires using a mask value such that [pfn, pfn+pages) all lie within the flushed size-aligned region. This is not normally an issue because iova.c always allocates iovas that are aligned to their size. However, iovas which come from other sources (e.g. userspace via VFIO) may not be aligned. To properly flush the IOTLB, both the start and end pfns need to be equal after applying the mask. That means that the most efficient mask to use is the index of the lowest bit that is equal where all higher bits are also equal. For example, if pfn=0x17f and pages=3, then end_pfn=0x181, so the smallest mask we can use is 8. Any differences above the highest bit of pages are due to carrying, so by xnor'ing pfn and end_pfn and then masking out the lower order bits based on pages, we get 0xffffff00, where the first set bit is the mask we want to use. Fixes: 6fe1010d6d9c ("vfio/type1: DMA unmap chunking") Cc: stable(a)vger.kernel.org Signed-off-by: David Stevens <stevensd(a)chromium.org> Reviewed-by: Kevin Tian <kevin.tian(a)intel.com> Link: https://lore.kernel.org/r/20220401022430.1262215-1-stevensd@google.com Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> --- drivers/iommu/intel/iommu.c | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index df5c62ecf942..0ea47e17b379 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1588,7 +1588,8 @@ static void iommu_flush_iotlb_psi(struct intel_iommu *iommu, unsigned long pfn, unsigned int pages, int ih, int map) { - unsigned int mask = ilog2(__roundup_pow_of_two(pages)); + unsigned int aligned_pages = __roundup_pow_of_two(pages); + unsigned int mask = ilog2(aligned_pages); uint64_t addr = (uint64_t)pfn << VTD_PAGE_SHIFT; u16 did = domain->iommu_did[iommu->seq_id]; @@ -1600,10 +1601,30 @@ static void iommu_flush_iotlb_psi(struct intel_iommu *iommu, if (domain_use_first_level(domain)) { qi_flush_piotlb(iommu, did, PASID_RID2PASID, addr, pages, ih); } else { + unsigned long bitmask = aligned_pages - 1; + + /* + * PSI masks the low order bits of the base address. If the + * address isn't aligned to the mask, then compute a mask value + * needed to ensure the target range is flushed. + */ + if (unlikely(bitmask & pfn)) { + unsigned long end_pfn = pfn + pages - 1, shared_bits; + + /* + * Since end_pfn <= pfn + bitmask, the only way bits + * higher than bitmask can differ in pfn and end_pfn is + * by carrying. This means after masking out bitmask, + * high bits starting with the first set bit in + * shared_bits are all equal in both pfn and end_pfn. + */ + shared_bits = ~(pfn ^ end_pfn) & ~bitmask; + mask = shared_bits ? __ffs(shared_bits) : BITS_PER_LONG; + } + /* * Fallback to domain selective flush if no PSI support or - * the size is too big. PSI requires page size to be 2 ^ x, - * and the base address is naturally aligned to the size. + * the size is too big. */ if (!cap_pgsel_inv(iommu->cap) || mask > cap_max_amask_val(iommu->cap)) -- 2.25.1

2 years, 9 months

1
0
0 0

+ revert-fs-binfmt_elf-use-pt_load-p_align-values-for-static-pie.patch added to -mm tree

by Andrew Morton

The patch titled Subject: revert "fs/binfmt_elf: use PT_LOAD p_align values for static PIE" has been added to the -mm tree. Its filename is revert-fs-binfmt_elf-use-pt_load-p_align-values-for-static-pie.patch This patch should soon appear at https://ozlabs.org/~akpm/mmots/broken-out/revert-fs-binfmt_elf-use-pt_load-… and later at https://ozlabs.org/~akpm/mmotm/broken-out/revert-fs-binfmt_elf-use-pt_load-… 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 and is updated there every 3-4 working days ------------------------------------------------------ From: Andrew Morton <akpm(a)linux-foundation.org> Subject: revert "fs/binfmt_elf: use PT_LOAD p_align values for static PIE" Despite Mike's attempted fix (925346c129da117122), regressions reports continue: https://lore.kernel.org/lkml/cb5b81bd-9882-e5dc-cd22-54bdbaaefbbc@leemhuis.… https://bugzilla.kernel.org/show_bug.cgi?id=215720 https://lkml.kernel.org/r/b685f3d0-da34-531d-1aa9-479accd3e21b@leemhuis.info So revert this patch. Fixes: 9630f0d60fec ("fs/binfmt_elf: use PT_LOAD p_align values for static PIE") Cc: Alexey Dobriyan <adobriyan(a)gmail.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Chris Kennelly <ckennelly(a)google.com> Cc: David Rientjes <rientjes(a)google.com> Cc: Fangrui Song <maskray(a)google.com> Cc: H.J. Lu <hjl.tools(a)gmail.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Ian Rogers <irogers(a)google.com> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Nick Desaulniers <ndesaulniers(a)google.com> Cc: Sandeep Patil <sspatil(a)google.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Song Liu <songliubraving(a)fb.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Thorsten Leemhuis <regressions(a)leemhuis.info> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/binfmt_elf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/binfmt_elf.c~revert-fs-binfmt_elf-use-pt_load-p_align-values-for-static-pie +++ a/fs/binfmt_elf.c @@ -1117,11 +1117,11 @@ out_free_interp: * independently randomized mmap region (0 load_bias * without MAP_FIXED nor MAP_FIXED_NOREPLACE). */ - alignment = maximum_alignment(elf_phdata, elf_ex->e_phnum); - if (alignment > ELF_MIN_ALIGN) { + if (interpreter) { load_bias = ELF_ET_DYN_BASE; if (current->flags & PF_RANDOMIZE) load_bias += arch_mmap_rnd(); + alignment = maximum_alignment(elf_phdata, elf_ex->e_phnum); if (alignment) load_bias &= ~(alignment - 1); elf_flags |= MAP_FIXED_NOREPLACE; _ Patches currently in -mm which might be from akpm(a)linux-foundation.org are mm-list_lruc-revert-mm-list_lru-optimize-memcg_reparent_list_lru_node.patch revert-fs-binfmt_elf-fix-pt_load-p_align-values-for-loaders.patch revert-fs-binfmt_elf-use-pt_load-p_align-values-for-static-pie.patch mm.patch mm-create-new-mm-swaph-header-file-fix.patch mm-shmem-make-shmem_init-return-void-fix.patch ksm-count-ksm-merging-pages-for-each-process-fix.patch mm-memory_hotplug-refactor-hotadd_init_pgdat-and-try_online_node-checkpatch-fixes.patch proc-fix-dentry-inode-overinstantiating-under-proc-pid-net-checkpatch-fixes.patch fs-proc-kcorec-remove-check-of-list-iterator-against-head-past-the-loop-body-fix.patch add-fat-messages-to-printk-index-checkpatch-fixes.patch linux-next-rejects.patch linux-next-git-rejects.patch mm-oom_killc-fix-vm_oom_kill_table-ifdeffery.patch

2 years, 9 months

1
0
0 0

+ revert-fs-binfmt_elf-fix-pt_load-p_align-values-for-loaders.patch added to -mm tree

by Andrew Morton

The patch titled Subject: revert "fs/binfmt_elf: fix PT_LOAD p_align values for loaders" has been added to the -mm tree. Its filename is revert-fs-binfmt_elf-fix-pt_load-p_align-values-for-loaders.patch This patch should soon appear at https://ozlabs.org/~akpm/mmots/broken-out/revert-fs-binfmt_elf-fix-pt_load-… and later at https://ozlabs.org/~akpm/mmotm/broken-out/revert-fs-binfmt_elf-fix-pt_load-… 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 and is updated there every 3-4 working days ------------------------------------------------------ From: Andrew Morton <akpm(a)linux-foundation.org> Subject: revert "fs/binfmt_elf: fix PT_LOAD p_align values for loaders" 925346c129da11 ("fs/binfmt_elf: fix PT_LOAD p_align values for loaders") is an attempt to fix regressions due to 9630f0d60fec5f ("fs/binfmt_elf: use PT_LOAD p_align values for static PIE"). But regressionss continue to be reported: https://lore.kernel.org/lkml/cb5b81bd-9882-e5dc-cd22-54bdbaaefbbc@leemhuis.… https://bugzilla.kernel.org/show_bug.cgi?id=215720 https://lkml.kernel.org/r/b685f3d0-da34-531d-1aa9-479accd3e21b@leemhuis.info This patch reverts the fix, so the original can also be reverted. Fixes: 925346c129da11 ("fs/binfmt_elf: fix PT_LOAD p_align values for loaders") Cc: H.J. Lu <hjl.tools(a)gmail.com> Cc: Chris Kennelly <ckennelly(a)google.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Alexey Dobriyan <adobriyan(a)gmail.com> Cc: Song Liu <songliubraving(a)fb.com> Cc: David Rientjes <rientjes(a)google.com> Cc: Ian Rogers <irogers(a)google.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Sandeep Patil <sspatil(a)google.com> Cc: Fangrui Song <maskray(a)google.com> Cc: Nick Desaulniers <ndesaulniers(a)google.com> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Thorsten Leemhuis <regressions(a)leemhuis.info> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/binfmt_elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/binfmt_elf.c~revert-fs-binfmt_elf-fix-pt_load-p_align-values-for-loaders +++ a/fs/binfmt_elf.c @@ -1118,7 +1118,7 @@ out_free_interp: * without MAP_FIXED nor MAP_FIXED_NOREPLACE). */ alignment = maximum_alignment(elf_phdata, elf_ex->e_phnum); - if (interpreter || alignment > ELF_MIN_ALIGN) { + if (alignment > ELF_MIN_ALIGN) { load_bias = ELF_ET_DYN_BASE; if (current->flags & PF_RANDOMIZE) load_bias += arch_mmap_rnd(); _ Patches currently in -mm which might be from akpm(a)linux-foundation.org are mm-list_lruc-revert-mm-list_lru-optimize-memcg_reparent_list_lru_node.patch revert-fs-binfmt_elf-fix-pt_load-p_align-values-for-loaders.patch revert-fs-binfmt_elf-use-pt_load-p_align-values-for-static-pie.patch mm.patch mm-create-new-mm-swaph-header-file-fix.patch mm-shmem-make-shmem_init-return-void-fix.patch ksm-count-ksm-merging-pages-for-each-process-fix.patch mm-memory_hotplug-refactor-hotadd_init_pgdat-and-try_online_node-checkpatch-fixes.patch proc-fix-dentry-inode-overinstantiating-under-proc-pid-net-checkpatch-fixes.patch fs-proc-kcorec-remove-check-of-list-iterator-against-head-past-the-loop-body-fix.patch add-fat-messages-to-printk-index-checkpatch-fixes.patch linux-next-rejects.patch linux-next-git-rejects.patch mm-oom_killc-fix-vm_oom_kill_table-ifdeffery.patch

2 years, 9 months

1
0
0 0

[stable:PATCH v5.4.188] KVM: arm64: Check arm64_get_bp_hardening_data() didn't return NULL

by James Morse

Will reports that with CONFIG_EXPERT=y and CONFIG_HARDEN_BRANCH_PREDICTOR=n, the kernel dereferences a NULL pointer during boot: [ 2.384444] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 2.384461] pstate: 20400085 (nzCv daIf +PAN -UAO) [ 2.384472] pc : cpu_hyp_reinit+0x114/0x30c [ 2.384476] lr : cpu_hyp_reinit+0x80/0x30c [ 2.384529] Call trace: [ 2.384533] cpu_hyp_reinit+0x114/0x30c [ 2.384537] _kvm_arch_hardware_enable+0x30/0x54 [ 2.384541] flush_smp_call_function_queue+0xe4/0x154 [ 2.384544] generic_smp_call_function_single_interrupt+0x10/0x18 [ 2.384549] ipi_handler+0x170/0x2b0 [ 2.384555] handle_percpu_devid_fasteoi_ipi+0x120/0x1cc [ 2.384560] __handle_domain_irq+0x9c/0xf4 [ 2.384563] gic_handle_irq+0x6c/0xe4 [ 2.384566] el1_irq+0xf0/0x1c0 [ 2.384570] arch_cpu_idle+0x28/0x44 [ 2.384574] do_idle+0x100/0x2a8 [ 2.384577] cpu_startup_entry+0x20/0x24 [ 2.384581] secondary_start_kernel+0x1b0/0x1cc [ 2.384589] Code: b9469d08 7100011f 540003ad 52800208 (f9400108) [ 2.384600] ---[ end trace 266d08dbf96ff143 ]--- [ 2.385171] Kernel panic - not syncing: Fatal exception in interrupt In this configuration arm64_get_bp_hardening_data() returns NULL. Add a check in kvm_get_hyp_vector(). Cc: Will Deacon <will(a)kernel.org> Link: https://lore.kernel.org/linux-arm-kernel/20220408120041.GB27685@willie-the-… Fixes: 26129ea2953b ("KVM: arm64: Add templates for BHB mitigation sequences") Cc: stable(a)vger.kernel.org # 5.4.x Signed-off-by: James Morse <james.morse(a)arm.com> --- arch/arm64/include/asm/kvm_mmu.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h index 78d110667c0c..ffe0aad96b17 100644 --- a/arch/arm64/include/asm/kvm_mmu.h +++ b/arch/arm64/include/asm/kvm_mmu.h @@ -479,7 +479,8 @@ static inline void *kvm_get_hyp_vector(void) int slot = -1; if ((cpus_have_const_cap(ARM64_HARDEN_BRANCH_PREDICTOR) || - cpus_have_const_cap(ARM64_SPECTRE_BHB)) && data->template_start) { + cpus_have_const_cap(ARM64_SPECTRE_BHB)) && + data && data->template_start) { vect = kern_hyp_va(kvm_ksym_ref(__bp_harden_hyp_vecs_start)); slot = data->hyp_vectors_slot; } -- 2.30.2

2 years, 9 months

2
1
0 0

[PATCH 0/1] mm: fix race between MADV_FREE reclaim and blkdev direct IO

by Mauricio Faria de Oliveira

commit 6c8e2a256915a223f6289f651d6b926cd7135c9e upstream. Backports for stable: - folio/page differences on 5.17, 5.16, 5.15, 5.10, 5.4, 4.19; - context lines differences on 4.14; - conditional/gate differences on 4.9; (changes described in each commit.) Test-case with good results on all versions (consistent values read on good/bad binary). Links: - FAILED: patch "[PATCH] mm: fix race between MADV_FREE reclaim and blkdev direct IO" failed to apply to <version>-stable tree - 5.17 https://lore.kernel.org/stable/1648897548136182@kroah.com/ - 5.16 https://lore.kernel.org/stable/164889755413570@kroah.com/ - 5.15 https://lore.kernel.org/stable/1648897560105145@kroah.com/ - 5.10 https://lore.kernel.org/stable/1648897566131152@kroah.com/ - 5.4 https://lore.kernel.org/stable/1648897573389@kroah.com/ - 4.19 https://lore.kernel.org/stable/1648897585112208@kroah.com/ - 4.14 https://lore.kernel.org/stable/1648897579250122@kroah.com/ The 4.9 version is also affected; there was an issue w/ the Fixes: commit id from v4 not picked up in mainline -- it should cover 4.9 (also described in each commits). cheers, -- Mauricio linux-5.17.y: === Original: + uname -rv 5.17.1-dirty #4 SMP PREEMPT Thu Apr 7 16:58:35 UTC 2022 ... + mv test good + ./good 0x7fe09a90a000: 0x79 0x7fe09a90b000: 0x79 0x7fe09a90c000: 0x79 0x7fe09a90d000: 0x79 + mv good bad + ./bad 0x7f6fd0a41000: 0x0 0x7f6fd0a42000: 0x0 0x7f6fd0a43000: 0x0 0x7f6fd0a44000: 0x0 Patched: + uname -rv 5.17.1-00001-g68e35ffe374c-dirty #3 SMP PREEMPT Thu Apr 7 15:10:56 UTC 2022 ... + mv test good + ./good 0x7fa65e4f5000: 0x79 0x7fa65e4f6000: 0x79 0x7fa65e4f7000: 0x79 0x7fa65e4f8000: 0x79 + mv good bad + ./bad 0x7fa6b92d7000: 0x79 0x7fa6b92d8000: 0x79 0x7fa6b92d9000: 0x79 0x7fa6b92da000: 0x79 linux-5.16.y: === Original: + uname -rv 5.16.18+ #1 SMP PREEMPT Thu Apr 7 15:17:17 UTC 2022 ... + mv test good + ./good 0x7fc0a4634000: 0x79 0x7fc0a4635000: 0x79 0x7fc0a4636000: 0x79 0x7fc0a4637000: 0x79 + mv good bad + ./bad 0x7fe5bbd8b000: 0x0 0x7fe5bbd8c000: 0x0 0x7fe5bbd8d000: 0x0 0x7fe5bbd8e000: 0x79 Patched: + uname -rv 5.16.18+ #2 SMP PREEMPT Thu Apr 7 15:22:21 UTC 2022 ... + mv test good + ./good 0x7f98cbe1d000: 0x79 0x7f98cbe1e000: 0x79 0x7f98cbe1f000: 0x79 0x7f98cbe20000: 0x79 + mv good bad + ./bad 0x7f0194098000: 0x79 0x7f0194099000: 0x79 0x7f019409a000: 0x79 0x7f019409b000: 0x79 linux-5.15.y: === Original: + uname -rv 5.15.32+ #2 SMP Thu Apr 7 15:38:32 UTC 2022 ... + mv test good + ./good 0x7f45b2dcd000: 0x79 0x7f45b2dce000: 0x79 0x7f45b2dcf000: 0x79 0x7f45b2dd0000: 0x79 + mv good bad + ./bad 0x7f477d3a2000: 0x0 0x7f477d3a3000: 0x0 0x7f477d3a4000: 0x0 0x7f477d3a5000: 0x0 Patched: + uname -rv 5.15.32+ #3 SMP Thu Apr 7 15:40:33 UTC 2022 ... + mv test good + ./good 0x7f918fc47000: 0x79 0x7f918fc48000: 0x79 0x7f918fc49000: 0x79 0x7f918fc4a000: 0x79 + mv good bad + ./bad 0x7fd6153f5000: 0x79 0x7fd6153f6000: 0x79 0x7fd6153f7000: 0x79 0x7fd6153f8000: 0x79 linux-5.10.y: === Original: + uname -rv 5.10.109+ #2 SMP Thu Apr 7 15:44:15 UTC 2022 ... + mv test good + ./good 0x7f94a3750000: 0x79 0x7f94a3751000: 0x79 0x7f94a3752000: 0x79 0x7f94a3753000: 0x79 + mv good bad + ./bad 0x7ff2e7938000: 0x0 0x7ff2e7939000: 0x0 0x7ff2e793a000: 0x0 0x7ff2e793b000: 0x0 Patched: + uname -rv 5.10.109+ #3 SMP Thu Apr 7 15:45:41 UTC 2022 ... + mv test good + ./good 0x7f2948d1d000: 0x79 0x7f2948d1e000: 0x79 0x7f2948d1f000: 0x79 0x7f2948d20000: 0x79 + mv good bad + ./bad 0x7fe22a9c6000: 0x79 0x7fe22a9c7000: 0x79 0x7fe22a9c8000: 0x79 0x7fe22a9c9000: 0x79 linux-5.4.y: === Original: + uname -rv 5.4.188+ #1 SMP Thu Apr 7 15:47:54 UTC 2022 ... + mv test good + ./good 0x7fc53e9a2000: 0x79 0x7fc53e9a3000: 0x79 0x7fc53e9a4000: 0x79 0x7fc53e9a5000: 0x79 + mv good bad + ./bad 0x7f88ce4fa000: 0x0 0x7f88ce4fb000: 0x0 0x7f88ce4fc000: 0x0 0x7f88ce4fd000: 0x0 Patched: + uname -rv 5.4.188+ #2 SMP Thu Apr 7 15:49:19 UTC 2022 ... + mv test good + ./good 0x7fd64b54c000: 0x79 0x7fd64b54d000: 0x79 0x7fd64b54e000: 0x79 0x7fd64b54f000: 0x79 + mv good bad + ./bad 0x7f15ba253000: 0x79 0x7f15ba254000: 0x79 0x7f15ba255000: 0x79 0x7f15ba256000: 0x79 linux-4.19.y: === Original: + uname -rv 4.19.237+ #1 SMP Thu Apr 7 15:51:11 UTC 2022 ... + mv test good + ./good 0x7fe8d78b0000: 0x79 0x7fe8d78b1000: 0x79 0x7fe8d78b2000: 0x79 0x7fe8d78b3000: 0x79 + mv good bad + ./bad 0x7f1d1f6e9000: 0x0 0x7f1d1f6ea000: 0x0 0x7f1d1f6eb000: 0x0 0x7f1d1f6ec000: 0x0 Patched: + uname -rv 4.19.237+ #2 SMP Thu Apr 7 15:52:24 UTC 2022 ... + mv test good + ./good 0x7f2bdb6c9000: 0x79 0x7f2bdb6ca000: 0x79 0x7f2bdb6cb000: 0x79 0x7f2bdb6cc000: 0x79 + mv good bad + ./bad 0x7f0e7af0f000: 0x79 0x7f0e7af10000: 0x79 0x7f0e7af11000: 0x79 0x7f0e7af12000: 0x79 linux-4.14.y: === Original: + uname -rv 4.14.275+ #2 SMP Thu Apr 7 15:55:08 UTC 2022 ... + mv test good + ./good 0x7fb22c1e2000: 0x79 0x7fb22c1e3000: 0x79 0x7fb22c1e4000: 0x79 0x7fb22c1e5000: 0x79 + mv good bad + ./bad 0x7fec8aad6000: 0x0 0x7fec8aad7000: 0x0 0x7fec8aad8000: 0x0 0x7fec8aad9000: 0x0 Patched: + uname -rv 4.14.275+ #3 SMP Thu Apr 7 16:23:22 UTC 2022 ... + mv test good + ./good 0x7fdfabd3f000: 0x79 0x7fdfabd40000: 0x79 0x7fdfabd41000: 0x79 0x7fdfabd42000: 0x79 + mv good bad + ./bad 0x7f25da5c1000: 0x79 0x7f25da5c2000: 0x79 0x7f25da5c3000: 0x79 0x7f25da5c4000: 0x79 linux-4.9.y: === # dd if=/dev/zero of=swap.img bs=1M count=1024 # mkswap swap.img # swapon swap.img Original: + uname -rv 4.9.309+ #2 SMP Thu Apr 7 16:30:41 UTC 2022 ... + mv test good + ./good 0x7fb2ec63d000: 0x79 0x7fb2ec63e000: 0x79 0x7fb2ec63f000: 0x79 0x7fb2ec640000: 0x79 + mv good bad + ./bad 0x7fdfaecf3000: 0x0 0x7fdfaecf4000: 0x0 0x7fdfaecf5000: 0x0 0x7fdfaecf6000: 0x0 Patched: + uname -rv 4.9.309+ #3 SMP Thu Apr 7 16:48:00 UTC 2022 ... + mv test good + ./good 0x7f8eeb60c000: 0x79 0x7f8eeb60d000: 0x79 0x7f8eeb60e000: 0x79 0x7f8eeb60f000: 0x79 + mv good bad + ./bad 0x7f4696d1e000: 0x79 0x7f4696d1f000: 0x79 0x7f4696d20000: 0x79 0x7f4696d21000: 0x79 -- 2.32.0

2 years, 9 months

2
9
0 0

[git:media_tree/fixes] media: si2157: unknown chip version Si2147-A30 ROM 0x50

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: si2157: unknown chip version Si2147-A30 ROM 0x50 Author: Piotr Chmura <chmooreck(a)gmail.com> Date: Thu Mar 31 17:55:50 2022 +0200 Fix firmware file names assignment in si2157 tuner, allow for running devices without firmware files needed. modprobe gives error: unknown chip version Si2147-A30 ROM 0x50 Device initialization is interrupted. Caused by: 1. table si2157_tuners has swapped fields rom_id and required vs struct si2157_tuner_info. 2. both firmware file names can be null for devices with required == false - device uses build-in firmware in this case Tested on this device: m07ca:1871 AVerMedia Technologies, Inc. TD310 DVB-T/T2/C dongle [mchehab: fix mangled patch] Link: https://bugzilla.kernel.org/show_bug.cgi?id=215726 Link: https://lore.kernel.org/lkml/5f660108-8812-383c-83e4-29ee0558d623@leemhuis.… Link: https://lore.kernel.org/linux-media/c4bcaff8-fbad-969e-ad47-e2c487ac02a1@gm… Fixes: 1c35ba3bf972 ("media: si2157: use a different namespace for firmware") Cc: stable(a)vger.kernel.org # 5.17.x Signed-off-by: Piotr Chmura <chmooreck(a)gmail.com> Tested-by: Robert Schlabbach <robert_s(a)gmx.net> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> drivers/media/tuners/si2157.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) --- diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c index 47029746b89e..0de587b412d4 100644 --- a/drivers/media/tuners/si2157.c +++ b/drivers/media/tuners/si2157.c @@ -77,16 +77,16 @@ err_mutex_unlock: } static const struct si2157_tuner_info si2157_tuners[] = { - { SI2141, false, 0x60, SI2141_60_FIRMWARE, SI2141_A10_FIRMWARE }, - { SI2141, false, 0x61, SI2141_61_FIRMWARE, SI2141_A10_FIRMWARE }, - { SI2146, false, 0x11, SI2146_11_FIRMWARE, NULL }, - { SI2147, false, 0x50, SI2147_50_FIRMWARE, NULL }, - { SI2148, true, 0x32, SI2148_32_FIRMWARE, SI2158_A20_FIRMWARE }, - { SI2148, true, 0x33, SI2148_33_FIRMWARE, SI2158_A20_FIRMWARE }, - { SI2157, false, 0x50, SI2157_50_FIRMWARE, SI2157_A30_FIRMWARE }, - { SI2158, false, 0x50, SI2158_50_FIRMWARE, SI2158_A20_FIRMWARE }, - { SI2158, false, 0x51, SI2158_51_FIRMWARE, SI2158_A20_FIRMWARE }, - { SI2177, false, 0x50, SI2177_50_FIRMWARE, SI2157_A30_FIRMWARE }, + { SI2141, 0x60, false, SI2141_60_FIRMWARE, SI2141_A10_FIRMWARE }, + { SI2141, 0x61, false, SI2141_61_FIRMWARE, SI2141_A10_FIRMWARE }, + { SI2146, 0x11, false, SI2146_11_FIRMWARE, NULL }, + { SI2147, 0x50, false, SI2147_50_FIRMWARE, NULL }, + { SI2148, 0x32, true, SI2148_32_FIRMWARE, SI2158_A20_FIRMWARE }, + { SI2148, 0x33, true, SI2148_33_FIRMWARE, SI2158_A20_FIRMWARE }, + { SI2157, 0x50, false, SI2157_50_FIRMWARE, SI2157_A30_FIRMWARE }, + { SI2158, 0x50, false, SI2158_50_FIRMWARE, SI2158_A20_FIRMWARE }, + { SI2158, 0x51, false, SI2158_51_FIRMWARE, SI2158_A20_FIRMWARE }, + { SI2177, 0x50, false, SI2177_50_FIRMWARE, SI2157_A30_FIRMWARE }, }; static int si2157_load_firmware(struct dvb_frontend *fe, @@ -178,7 +178,7 @@ static int si2157_find_and_load_firmware(struct dvb_frontend *fe) } } - if (!fw_name && !fw_alt_name) { + if (required && !fw_name && !fw_alt_name) { dev_err(&client->dev, "unknown chip version Si21%d-%c%c%c ROM 0x%02x\n", part_id, cmd.args[1], cmd.args[3], cmd.args[4], rom_id);

2 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2022