* [PATCH 4.18 01/22] EDAC: Add missing MEM_LRDDR4 entry in edac_mem_types[]
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 02/22] pty: fix O_CLOEXEC for TIOCGPTPEER Greg Kroah-Hartman
` (19 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Takashi Iwai, Mauro Carvalho Chehab,
Yazen Ghannam, linux-edac, Borislav Petkov
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit b748f2de4b2f578599f46c6000683a8da755bf68 upstream.
The edac_mem_types[] array misses a MEM_LRDDR4 entry, which leads to
NULL pointer dereference when accessed via sysfs or such.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Yazen Ghannam <Yazen.Ghannam@amd.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20180810141426.8918-1-tiwai@suse.de
Fixes: 1e8096bb2031 ("EDAC: Add LRDDR4 DRAM type")
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/edac/edac_mc.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -215,6 +215,7 @@ const char * const edac_mem_types[] = {
[MEM_LRDDR3] = "Load-Reduced-DDR3-RAM",
[MEM_DDR4] = "Unbuffered-DDR4",
[MEM_RDDR4] = "Registered-DDR4",
+ [MEM_LRDDR4] = "Load-Reduced-DDR4-RAM",
[MEM_NVDIMM] = "Non-volatile-RAM",
};
EXPORT_SYMBOL_GPL(edac_mem_types);
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 02/22] pty: fix O_CLOEXEC for TIOCGPTPEER
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 01/22] EDAC: Add missing MEM_LRDDR4 entry in edac_mem_types[] Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 03/22] mm: Allow non-direct-map arguments to free_reserved_area() Greg Kroah-Hartman
` (18 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Matthijs van Duin, Aleksa Sarai
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthijs van Duin <matthijsvanduin@gmail.com>
commit 36ecc1481dc8d8c52d43ba18c6b642c1d2fde789 upstream.
It was being ignored because the flags were not passed to fd allocation.
Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl")
Signed-off-by: Matthijs van Duin <matthijsvanduin@gmail.com>
Acked-by: Aleksa Sarai <asarai@suse.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/pty.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -625,7 +625,7 @@ int ptm_open_peer(struct file *master, s
if (tty->driver != ptm_driver)
return -EIO;
- fd = get_unused_fd_flags(0);
+ fd = get_unused_fd_flags(flags);
if (fd < 0) {
retval = fd;
goto err;
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 03/22] mm: Allow non-direct-map arguments to free_reserved_area()
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 01/22] EDAC: Add missing MEM_LRDDR4 entry in edac_mem_types[] Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 02/22] pty: fix O_CLOEXEC for TIOCGPTPEER Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 04/22] x86/mm/init: Pass unconverted symbol addresses to free_init_pages() Greg Kroah-Hartman
` (17 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dave Hansen, Thomas Gleixner,
keescook, aarcange, jgross, jpoimboe, peterz, hughd, torvalds,
bp, luto, ak
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Hansen <dave.hansen@linux.intel.com>
commit 0d83432811f26871295a9bc24d3c387924da6071 upstream.
free_reserved_area() takes pointers as arguments to show which addresses
should be freed. However, it does this in a somewhat ambiguous way. If it
gets a kernel direct map address, it always works. However, if it gets an
address that is part of the kernel image alias mapping, it can fail.
It fails if all of the following happen:
* The specified address is part of the kernel image alias
* Poisoning is requested (forcing a memset())
* The address is in a read-only portion of the kernel image
The memset() fails on the read-only mapping, of course.
free_reserved_area() *is* called both on the direct map and on kernel image
alias addresses. We've just lucked out thus far that the kernel image
alias areas it gets used on are read-write. I'm fairly sure this has been
just a happy accident.
It is quite easy to make free_reserved_area() work for all cases: just
convert the address to a direct map address before doing the memset(), and
do this unconditionally. There is little chance of a regression here
because we previously did a virt_to_page() on the address for the memset,
so we know these are not highmem pages for which virt_to_page() would fail.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: keescook@google.com
Cc: aarcange@redhat.com
Cc: jgross@suse.com
Cc: jpoimboe@redhat.com
Cc: gregkh@linuxfoundation.org
Cc: peterz@infradead.org
Cc: hughd@google.com
Cc: torvalds@linux-foundation.org
Cc: bp@alien8.de
Cc: luto@kernel.org
Cc: ak@linux.intel.com
Cc: Kees Cook <keescook@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>
Link: https://lkml.kernel.org/r/20180802225826.1287AE3E@viggo.jf.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/page_alloc.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6939,9 +6939,21 @@ unsigned long free_reserved_area(void *s
start = (void *)PAGE_ALIGN((unsigned long)start);
end = (void *)((unsigned long)end & PAGE_MASK);
for (pos = start; pos < end; pos += PAGE_SIZE, pages++) {
+ struct page *page = virt_to_page(pos);
+ void *direct_map_addr;
+
+ /*
+ * 'direct_map_addr' might be different from 'pos'
+ * because some architectures' virt_to_page()
+ * work with aliases. Getting the direct map
+ * address ensures that we get a _writeable_
+ * alias for the memset().
+ */
+ direct_map_addr = page_address(page);
if ((unsigned int)poison <= 0xFF)
- memset(pos, poison, PAGE_SIZE);
- free_reserved_page(virt_to_page(pos));
+ memset(direct_map_addr, poison, PAGE_SIZE);
+
+ free_reserved_page(page);
}
if (pages && s)
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 04/22] x86/mm/init: Pass unconverted symbol addresses to free_init_pages()
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 03/22] mm: Allow non-direct-map arguments to free_reserved_area() Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 05/22] x86/mm/init: Add helper for freeing kernel image pages Greg Kroah-Hartman
` (16 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dave Hansen, Thomas Gleixner,
keescook, aarcange, jgross, jpoimboe, peterz, hughd, torvalds,
bp, luto, ak
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Hansen <dave.hansen@linux.intel.com>
commit 9f515cdb411ef34f1aaf4c40bb0c932cf6db5de1 upstream.
The x86 code has several places where it frees parts of kernel image:
1. Unused SMP alternative
2. __init code
3. The hole between text and rodata
4. The hole between rodata and data
We call free_init_pages() to do this. Strangely, we convert the symbol
addresses to kernel direct map addresses in some cases (#3, #4) but not
others (#1, #2).
The virt_to_page() and the other code in free_reserved_area() now works
fine for for symbol addresses on x86, so don't bother converting the
addresses to direct map addresses before freeing them.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: keescook@google.com
Cc: aarcange@redhat.com
Cc: jgross@suse.com
Cc: jpoimboe@redhat.com
Cc: gregkh@linuxfoundation.org
Cc: peterz@infradead.org
Cc: hughd@google.com
Cc: torvalds@linux-foundation.org
Cc: bp@alien8.de
Cc: luto@kernel.org
Cc: ak@linux.intel.com
Cc: Kees Cook <keescook@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>
Link: https://lkml.kernel.org/r/20180802225828.89B2D0E2@viggo.jf.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/mm/init_64.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1283,12 +1283,8 @@ void mark_rodata_ro(void)
set_memory_ro(start, (end-start) >> PAGE_SHIFT);
#endif
- free_init_pages("unused kernel",
- (unsigned long) __va(__pa_symbol(text_end)),
- (unsigned long) __va(__pa_symbol(rodata_start)));
- free_init_pages("unused kernel",
- (unsigned long) __va(__pa_symbol(rodata_end)),
- (unsigned long) __va(__pa_symbol(_sdata)));
+ free_init_pages("unused kernel", text_end, rodata_start);
+ free_init_pages("unused kernel", rodata_end, _sdata);
debug_checkwx();
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 05/22] x86/mm/init: Add helper for freeing kernel image pages
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 04/22] x86/mm/init: Pass unconverted symbol addresses to free_init_pages() Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 06/22] x86/mm/init: Remove freed kernel image areas from alias mapping Greg Kroah-Hartman
` (15 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dave Hansen, Thomas Gleixner,
keescook, aarcange, jgross, jpoimboe, peterz, hughd, torvalds,
bp, luto, ak
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Hansen <dave.hansen@linux.intel.com>
commit 6ea2738e0ca0e626c75202fb051c1e88d7a950fa upstream.
When chunks of the kernel image are freed, free_init_pages() is used
directly. Consolidate the three sites that do this. Also update the
string to give an incrementally better description of that memory versus
what was there before.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: keescook@google.com
Cc: aarcange@redhat.com
Cc: jgross@suse.com
Cc: jpoimboe@redhat.com
Cc: gregkh@linuxfoundation.org
Cc: peterz@infradead.org
Cc: hughd@google.com
Cc: torvalds@linux-foundation.org
Cc: bp@alien8.de
Cc: luto@kernel.org
Cc: ak@linux.intel.com
Cc: Kees Cook <keescook@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>
Link: https://lkml.kernel.org/r/20180802225829.FE0E32EA@viggo.jf.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/processor.h | 1 +
arch/x86/mm/init.c | 15 ++++++++++++---
arch/x86/mm/init_64.c | 4 ++--
3 files changed, 15 insertions(+), 5 deletions(-)
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -971,6 +971,7 @@ static inline uint32_t hypervisor_cpuid_
extern unsigned long arch_align_stack(unsigned long sp);
extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
+extern void free_kernel_image_pages(void *begin, void *end);
void default_idle(void);
#ifdef CONFIG_XEN
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -775,13 +775,22 @@ void free_init_pages(char *what, unsigne
}
}
+/*
+ * begin/end can be in the direct map or the "high kernel mapping"
+ * used for the kernel image only. free_init_pages() will do the
+ * right thing for either kind of address.
+ */
+void free_kernel_image_pages(void *begin, void *end)
+{
+ free_init_pages("unused kernel image",
+ (unsigned long)begin, (unsigned long)end);
+}
+
void __ref free_initmem(void)
{
e820__reallocate_tables();
- free_init_pages("unused kernel",
- (unsigned long)(&__init_begin),
- (unsigned long)(&__init_end));
+ free_kernel_image_pages(&__init_begin, &__init_end);
}
#ifdef CONFIG_BLK_DEV_INITRD
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1283,8 +1283,8 @@ void mark_rodata_ro(void)
set_memory_ro(start, (end-start) >> PAGE_SHIFT);
#endif
- free_init_pages("unused kernel", text_end, rodata_start);
- free_init_pages("unused kernel", rodata_end, _sdata);
+ free_kernel_image_pages((void *)text_end, (void *)rodata_start);
+ free_kernel_image_pages((void *)rodata_end, (void *)_sdata);
debug_checkwx();
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 06/22] x86/mm/init: Remove freed kernel image areas from alias mapping
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 05/22] x86/mm/init: Add helper for freeing kernel image pages Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 07/22] powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2 Greg Kroah-Hartman
` (14 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dave Hansen, Thomas Gleixner,
Kees Cook, Andrea Arcangeli, Juergen Gross, Josh Poimboeuf,
Peter Zijlstra, Hugh Dickins, Linus Torvalds, Borislav Petkov,
Andy Lutomirski, Andi Kleen, Joerg Roedel
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Hansen <dave.hansen@linux.intel.com>
commit c40a56a7818cfe735fc93a69e1875f8bba834483 upstream.
The kernel image is mapped into two places in the virtual address space
(addresses without KASLR, of course):
1. The kernel direct map (0xffff880000000000)
2. The "high kernel map" (0xffffffff81000000)
We actually execute out of #2. If we get the address of a kernel symbol,
it points to #2, but almost all physical-to-virtual translations point to
Parts of the "high kernel map" alias are mapped in the userspace page
tables with the Global bit for performance reasons. The parts that we map
to userspace do not (er, should not) have secrets. When PTI is enabled then
the global bit is usually not set in the high mapping and just used to
compensate for poor performance on systems which lack PCID.
This is fine, except that some areas in the kernel image that are adjacent
to the non-secret-containing areas are unused holes. We free these holes
back into the normal page allocator and reuse them as normal kernel memory.
The memory will, of course, get *used* via the normal map, but the alias
mapping is kept.
This otherwise unused alias mapping of the holes will, by default keep the
Global bit, be mapped out to userspace, and be vulnerable to Meltdown.
Remove the alias mapping of these pages entirely. This is likely to
fracture the 2M page mapping the kernel image near these areas, but this
should affect a minority of the area.
The pageattr code changes *all* aliases mapping the physical pages that it
operates on (by default). We only want to modify a single alias, so we
need to tweak its behavior.
This unmapping behavior is currently dependent on PTI being in place.
Going forward, we should at least consider doing this for all
configurations. Having an extra read-write alias for memory is not exactly
ideal for debugging things like random memory corruption and this does
undercut features like DEBUG_PAGEALLOC or future work like eXclusive Page
Frame Ownership (XPFO).
Before this patch:
current_kernel:---[ High Kernel Mapping ]---
current_kernel-0xffffffff80000000-0xffffffff81000000 16M pmd
current_kernel-0xffffffff81000000-0xffffffff81e00000 14M ro PSE GLB x pmd
current_kernel-0xffffffff81e00000-0xffffffff81e11000 68K ro GLB x pte
current_kernel-0xffffffff81e11000-0xffffffff82000000 1980K RW NX pte
current_kernel-0xffffffff82000000-0xffffffff82600000 6M ro PSE GLB NX pmd
current_kernel-0xffffffff82600000-0xffffffff82c00000 6M RW PSE NX pmd
current_kernel-0xffffffff82c00000-0xffffffff82e00000 2M RW NX pte
current_kernel-0xffffffff82e00000-0xffffffff83200000 4M RW PSE NX pmd
current_kernel-0xffffffff83200000-0xffffffffa0000000 462M pmd
current_user:---[ High Kernel Mapping ]---
current_user-0xffffffff80000000-0xffffffff81000000 16M pmd
current_user-0xffffffff81000000-0xffffffff81e00000 14M ro PSE GLB x pmd
current_user-0xffffffff81e00000-0xffffffff81e11000 68K ro GLB x pte
current_user-0xffffffff81e11000-0xffffffff82000000 1980K RW NX pte
current_user-0xffffffff82000000-0xffffffff82600000 6M ro PSE GLB NX pmd
current_user-0xffffffff82600000-0xffffffffa0000000 474M pmd
After this patch:
current_kernel:---[ High Kernel Mapping ]---
current_kernel-0xffffffff80000000-0xffffffff81000000 16M pmd
current_kernel-0xffffffff81000000-0xffffffff81e00000 14M ro PSE GLB x pmd
current_kernel-0xffffffff81e00000-0xffffffff81e11000 68K ro GLB x pte
current_kernel-0xffffffff81e11000-0xffffffff82000000 1980K pte
current_kernel-0xffffffff82000000-0xffffffff82400000 4M ro PSE GLB NX pmd
current_kernel-0xffffffff82400000-0xffffffff82488000 544K ro NX pte
current_kernel-0xffffffff82488000-0xffffffff82600000 1504K pte
current_kernel-0xffffffff82600000-0xffffffff82c00000 6M RW PSE NX pmd
current_kernel-0xffffffff82c00000-0xffffffff82c0d000 52K RW NX pte
current_kernel-0xffffffff82c0d000-0xffffffff82dc0000 1740K pte
current_user:---[ High Kernel Mapping ]---
current_user-0xffffffff80000000-0xffffffff81000000 16M pmd
current_user-0xffffffff81000000-0xffffffff81e00000 14M ro PSE GLB x pmd
current_user-0xffffffff81e00000-0xffffffff81e11000 68K ro GLB x pte
current_user-0xffffffff81e11000-0xffffffff82000000 1980K pte
current_user-0xffffffff82000000-0xffffffff82400000 4M ro PSE GLB NX pmd
current_user-0xffffffff82400000-0xffffffff82488000 544K ro NX pte
current_user-0xffffffff82488000-0xffffffff82600000 1504K pte
current_user-0xffffffff82600000-0xffffffffa0000000 474M pmd
[ tglx: Do not unmap on 32bit as there is only one mapping ]
Fixes: 0f561fce4d69 ("x86/pti: Enable global pages for shared areas")
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kees Cook <keescook@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Joerg Roedel <jroedel@suse.de>
Link: https://lkml.kernel.org/r/20180802225831.5F6A2BFC@viggo.jf.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/set_memory.h | 1 +
arch/x86/mm/init.c | 26 ++++++++++++++++++++++++--
arch/x86/mm/pageattr.c | 13 +++++++++++++
3 files changed, 38 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/set_memory.h
+++ b/arch/x86/include/asm/set_memory.h
@@ -46,6 +46,7 @@ int set_memory_np(unsigned long addr, in
int set_memory_4k(unsigned long addr, int numpages);
int set_memory_encrypted(unsigned long addr, int numpages);
int set_memory_decrypted(unsigned long addr, int numpages);
+int set_memory_np_noalias(unsigned long addr, int numpages);
int set_memory_array_uc(unsigned long *addr, int addrinarray);
int set_memory_array_wc(unsigned long *addr, int addrinarray);
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -782,8 +782,30 @@ void free_init_pages(char *what, unsigne
*/
void free_kernel_image_pages(void *begin, void *end)
{
- free_init_pages("unused kernel image",
- (unsigned long)begin, (unsigned long)end);
+ unsigned long begin_ul = (unsigned long)begin;
+ unsigned long end_ul = (unsigned long)end;
+ unsigned long len_pages = (end_ul - begin_ul) >> PAGE_SHIFT;
+
+
+ free_init_pages("unused kernel image", begin_ul, end_ul);
+
+ /*
+ * PTI maps some of the kernel into userspace. For performance,
+ * this includes some kernel areas that do not contain secrets.
+ * Those areas might be adjacent to the parts of the kernel image
+ * being freed, which may contain secrets. Remove the "high kernel
+ * image mapping" for these freed areas, ensuring they are not even
+ * potentially vulnerable to Meltdown regardless of the specific
+ * optimizations PTI is currently using.
+ *
+ * The "noalias" prevents unmapping the direct map alias which is
+ * needed to access the freed pages.
+ *
+ * This is only valid for 64bit kernels. 32bit has only one mapping
+ * which can't be treated in this way for obvious reasons.
+ */
+ if (IS_ENABLED(CONFIG_X86_64) && cpu_feature_enabled(X86_FEATURE_PTI))
+ set_memory_np_noalias(begin_ul, len_pages);
}
void __ref free_initmem(void)
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -53,6 +53,7 @@ static DEFINE_SPINLOCK(cpa_lock);
#define CPA_FLUSHTLB 1
#define CPA_ARRAY 2
#define CPA_PAGES_ARRAY 4
+#define CPA_NO_CHECK_ALIAS 8 /* Do not search for aliases */
#ifdef CONFIG_PROC_FS
static unsigned long direct_pages_count[PG_LEVEL_NUM];
@@ -1486,6 +1487,9 @@ static int change_page_attr_set_clr(unsi
/* No alias checking for _NX bit modifications */
checkalias = (pgprot_val(mask_set) | pgprot_val(mask_clr)) != _PAGE_NX;
+ /* Has caller explicitly disabled alias checking? */
+ if (in_flag & CPA_NO_CHECK_ALIAS)
+ checkalias = 0;
ret = __change_page_attr_set_clr(&cpa, checkalias);
@@ -1772,6 +1776,15 @@ int set_memory_np(unsigned long addr, in
return change_page_attr_clear(&addr, numpages, __pgprot(_PAGE_PRESENT), 0);
}
+int set_memory_np_noalias(unsigned long addr, int numpages)
+{
+ int cpa_flags = CPA_NO_CHECK_ALIAS;
+
+ return change_page_attr_set_clr(&addr, numpages, __pgprot(0),
+ __pgprot(_PAGE_PRESENT), 0,
+ cpa_flags, NULL);
+}
+
int set_memory_4k(unsigned long addr, int numpages)
{
return change_page_attr_set_clr(&addr, numpages, __pgprot(0),
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 07/22] powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 06/22] x86/mm/init: Remove freed kernel image areas from alias mapping Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 08/22] ext4: fix spectre gadget in ext4_mb_regular_allocator() Greg Kroah-Hartman
` (13 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Michael Ellerman
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Ellerman <mpe@ellerman.id.au>
commit 6d44acae1937b81cf8115ada8958e04f601f3f2e upstream.
When I added the spectre_v2 information in sysfs, I included the
availability of the ori31 speculation barrier.
Although the ori31 barrier can be used to mitigate v2, it's primarily
intended as a spectre v1 mitigation. Spectre v2 is mitigated by
hardware changes.
So rework the sysfs files to show the ori31 information in the
spectre_v1 file, rather than v2.
Currently we display eg:
$ grep . spectre_v*
spectre_v1:Mitigation: __user pointer sanitization
spectre_v2:Mitigation: Indirect branch cache disabled, ori31 speculation barrier enabled
After:
$ grep . spectre_v*
spectre_v1:Mitigation: __user pointer sanitization, ori31 speculation barrier enabled
spectre_v2:Mitigation: Indirect branch cache disabled
Fixes: d6fbe1c55c55 ("powerpc/64s: Wire up cpu_show_spectre_v2()")
Cc: stable@vger.kernel.org # v4.17+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/security.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -117,25 +117,35 @@ ssize_t cpu_show_meltdown(struct device
ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr, char *buf)
{
- if (!security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR))
- return sprintf(buf, "Not affected\n");
+ struct seq_buf s;
+
+ seq_buf_init(&s, buf, PAGE_SIZE - 1);
+
+ if (security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR)) {
+ if (barrier_nospec_enabled)
+ seq_buf_printf(&s, "Mitigation: __user pointer sanitization");
+ else
+ seq_buf_printf(&s, "Vulnerable");
- if (barrier_nospec_enabled)
- return sprintf(buf, "Mitigation: __user pointer sanitization\n");
+ if (security_ftr_enabled(SEC_FTR_SPEC_BAR_ORI31))
+ seq_buf_printf(&s, ", ori31 speculation barrier enabled");
- return sprintf(buf, "Vulnerable\n");
+ seq_buf_printf(&s, "\n");
+ } else
+ seq_buf_printf(&s, "Not affected\n");
+
+ return s.len;
}
ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr, char *buf)
{
- bool bcs, ccd, ori;
struct seq_buf s;
+ bool bcs, ccd;
seq_buf_init(&s, buf, PAGE_SIZE - 1);
bcs = security_ftr_enabled(SEC_FTR_BCCTRL_SERIALISED);
ccd = security_ftr_enabled(SEC_FTR_COUNT_CACHE_DISABLED);
- ori = security_ftr_enabled(SEC_FTR_SPEC_BAR_ORI31);
if (bcs || ccd) {
seq_buf_printf(&s, "Mitigation: ");
@@ -151,9 +161,6 @@ ssize_t cpu_show_spectre_v2(struct devic
} else
seq_buf_printf(&s, "Vulnerable");
- if (ori)
- seq_buf_printf(&s, ", ori31 speculation barrier enabled");
-
seq_buf_printf(&s, "\n");
return s.len;
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 08/22] ext4: fix spectre gadget in ext4_mb_regular_allocator()
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 07/22] powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2 Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 09/22] drm/i915/kvmgt: Fix potential Spectre v1 Greg Kroah-Hartman
` (12 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Josh Poimboeuf, Jeremy Cline, Theodore Tso
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeremy Cline <jcline@redhat.com>
commit 1a5d5e5d51e75a5bca67dadbcea8c841934b7b85 upstream.
'ac->ac_g_ex.fe_len' is a user-controlled value which is used in the
derivation of 'ac->ac_2order'. 'ac->ac_2order', in turn, is used to
index arrays which makes it a potential spectre gadget. Fix this by
sanitizing the value assigned to 'ac->ac2_order'. This covers the
following accesses found with the help of smatch:
* fs/ext4/mballoc.c:1896 ext4_mb_simple_scan_group() warn: potential
spectre issue 'grp->bb_counters' [w] (local cap)
* fs/ext4/mballoc.c:445 mb_find_buddy() warn: potential spectre issue
'EXT4_SB(e4b->bd_sb)->s_mb_offsets' [r] (local cap)
* fs/ext4/mballoc.c:446 mb_find_buddy() warn: potential spectre issue
'EXT4_SB(e4b->bd_sb)->s_mb_maxs' [r] (local cap)
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Jeremy Cline <jcline@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/mballoc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -14,6 +14,7 @@
#include <linux/log2.h>
#include <linux/module.h>
#include <linux/slab.h>
+#include <linux/nospec.h>
#include <linux/backing-dev.h>
#include <trace/events/ext4.h>
@@ -2140,7 +2141,8 @@ ext4_mb_regular_allocator(struct ext4_al
* This should tell if fe_len is exactly power of 2
*/
if ((ac->ac_g_ex.fe_len & (~(1 << (i - 1)))) == 0)
- ac->ac_2order = i - 1;
+ ac->ac_2order = array_index_nospec(i - 1,
+ sb->s_blocksize_bits + 2);
}
/* if stream allocation is enabled, use global goal */
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 09/22] drm/i915/kvmgt: Fix potential Spectre v1
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 08/22] ext4: fix spectre gadget in ext4_mb_regular_allocator() Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 10/22] drm/amdgpu/pm: " Greg Kroah-Hartman
` (11 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Gustavo A. R. Silva, Zhenyu Wang
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo A. R. Silva <gustavo@embeddedor.com>
commit de5372da605d3bca46e3102bab51b7e1c0e0a6f6 upstream.
info.index can be indirectly controlled by user-space, hence leading
to a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/gpu/drm/i915/gvt/kvmgt.c:1232 intel_vgpu_ioctl() warn:
potential spectre issue 'vgpu->vdev.region' [r]
Fix this by sanitizing info.index before indirectly using it to index
vgpu->vdev.region
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -43,6 +43,8 @@
#include <linux/mdev.h>
#include <linux/debugfs.h>
+#include <linux/nospec.h>
+
#include "i915_drv.h"
#include "gvt.h"
@@ -1084,7 +1086,8 @@ static long intel_vgpu_ioctl(struct mdev
} else if (cmd == VFIO_DEVICE_GET_REGION_INFO) {
struct vfio_region_info info;
struct vfio_info_cap caps = { .buf = NULL, .size = 0 };
- int i, ret;
+ unsigned int i;
+ int ret;
struct vfio_region_info_cap_sparse_mmap *sparse = NULL;
size_t size;
int nr_areas = 1;
@@ -1169,6 +1172,10 @@ static long intel_vgpu_ioctl(struct mdev
if (info.index >= VFIO_PCI_NUM_REGIONS +
vgpu->vdev.num_regions)
return -EINVAL;
+ info.index =
+ array_index_nospec(info.index,
+ VFIO_PCI_NUM_REGIONS +
+ vgpu->vdev.num_regions);
i = info.index - VFIO_PCI_NUM_REGIONS;
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 10/22] drm/amdgpu/pm: Fix potential Spectre v1
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 09/22] drm/i915/kvmgt: Fix potential Spectre v1 Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 14/22] PCI / ACPI / PM: Resume all bridges on suspend-to-RAM Greg Kroah-Hartman
` (10 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Gustavo A. R. Silva, Alex Deucher
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo A. R. Silva <gustavo@embeddedor.com>
commit ddf74e79a54070f277ae520722d3bab7f7a6c67a upstream.
idx can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:408 amdgpu_set_pp_force_state()
warn: potential spectre issue 'data.states'
Fix this by sanitizing idx before using it to index data.states
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -31,7 +31,7 @@
#include <linux/power_supply.h>
#include <linux/hwmon.h>
#include <linux/hwmon-sysfs.h>
-
+#include <linux/nospec.h>
static int amdgpu_debugfs_pm_init(struct amdgpu_device *adev);
@@ -393,6 +393,7 @@ static ssize_t amdgpu_set_pp_force_state
count = -EINVAL;
goto fail;
}
+ idx = array_index_nospec(idx, ARRAY_SIZE(data.states));
amdgpu_dpm_get_pp_num_states(adev, &data);
state = data.states[idx];
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 14/22] PCI / ACPI / PM: Resume all bridges on suspend-to-RAM
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 10/22] drm/amdgpu/pm: " Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 15/22] PCI: hotplug: Dont leak pci_slot on registration failure Greg Kroah-Hartman
` (9 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, teika kazura, Mika Westerberg,
Bjorn Helgaas, Rafael J. Wysocki
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 9d64b539b738fc181442caab95f1f76d9bd58539 upstream.
Commit 26112ddc254c (PCI / ACPI / PM: Resume bridges w/o drivers on
suspend-to-RAM) attempted to fix a functional regression resulting
from commit c62ec4610c40 (PM / core: Fix direct_complete handling
for devices with no callbacks) by resuming PCI bridges without
drivers (that is, "parallel PCI" ones) during system-wide suspend if
the target system state is not ACPI S0 (working state).
That turns out insufficient, however, as it is reported that, at
least in one case, the platform firmware gets confused if a PCIe
root port is suspended before entering the ACPI S3 sleep state.
That issue was exposed by commit 77b3729ca03 (PCI / PM: Use
SMART_SUSPEND and LEAVE_SUSPENDED flags for PCIe ports) that allowed
PCIe ports to stay in runtime suspend during system-wide suspend
(which is OK for suspend-to-idle, but turns out to be problematic
otherwise).
For this reason, drop the driver check from acpi_pci_need_resume()
and resume all bridges (including PCIe ports with drivers) during
system-wide suspend if the target system state is not ACPI S0.
[If the target system state is ACPI S0, it means suspend-to-idle
and the platform firmware is not going to be invoked to actually
suspend the system, so there is no need to resume the bridges in
that case.]
Fixes: 77b3729ca03 (PCI / PM: Use SMART_SUSPEND and LEAVE_SUSPENDED flags for PCIe ports)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200675
Reported-by: teika kazura <teika@gmx.com>
Tested-by: teika kazura <teika@gmx.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: 4.16+ <stable@vger.kernel.org> # 4.16+: 26112ddc254c (PCI / ACPI / PM: Resume bridges ...)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/pci-acpi.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -632,13 +632,11 @@ static bool acpi_pci_need_resume(struct
/*
* In some cases (eg. Samsung 305V4A) leaving a bridge in suspend over
* system-wide suspend/resume confuses the platform firmware, so avoid
- * doing that, unless the bridge has a driver that should take care of
- * the PM handling. According to Section 16.1.6 of ACPI 6.2, endpoint
+ * doing that. According to Section 16.1.6 of ACPI 6.2, endpoint
* devices are expected to be in D3 before invoking the S3 entry path
* from the firmware, so they should not be affected by this issue.
*/
- if (pci_is_bridge(dev) && !dev->driver &&
- acpi_target_system_state() != ACPI_STATE_S0)
+ if (pci_is_bridge(dev) && acpi_target_system_state() != ACPI_STATE_S0)
return true;
if (!adev || !acpi_device_power_manageable(adev))
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 15/22] PCI: hotplug: Dont leak pci_slot on registration failure
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 14/22] PCI / ACPI / PM: Resume all bridges on suspend-to-RAM Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 16/22] PCI: aardvark: Size bridges before resources allocation Greg Kroah-Hartman
` (8 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lukas Wunner, Bjorn Helgaas,
Greg Kroah-Hartman
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukas Wunner <lukas@wunner.de>
commit 4ce6435820d1f1cc2c2788e232735eb244bcc8a3 upstream.
If addition of sysfs files fails on registration of a hotplug slot, the
struct pci_slot as well as the entry in the slot_list is leaked. The
issue has been present since the hotplug core was introduced in 2002:
https://git.kernel.org/tglx/history/c/a8a2069f432c
Perhaps the idea was that even though sysfs addition fails, the slot
should still be usable. But that's not how drivers use the interface,
they abort probe if a non-zero value is returned.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org # v2.4.15+
Cc: Greg Kroah-Hartman <greg@kroah.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/hotplug/pci_hotplug_core.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/pci/hotplug/pci_hotplug_core.c
+++ b/drivers/pci/hotplug/pci_hotplug_core.c
@@ -438,8 +438,17 @@ int __pci_hp_register(struct hotplug_slo
list_add(&slot->slot_list, &pci_hotplug_slot_list);
result = fs_add_slot(pci_slot);
+ if (result)
+ goto err_list_del;
+
kobject_uevent(&pci_slot->kobj, KOBJ_ADD);
dbg("Added slot %s to the list\n", name);
+ goto out;
+
+err_list_del:
+ list_del(&slot->slot_list);
+ pci_slot->hotplug = NULL;
+ pci_destroy_slot(pci_slot);
out:
mutex_unlock(&pci_hp_mutex);
return result;
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 16/22] PCI: aardvark: Size bridges before resources allocation
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 15/22] PCI: hotplug: Dont leak pci_slot on registration failure Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 17/22] PCI: Skip MPS logic for Virtual Functions (VFs) Greg Kroah-Hartman
` (7 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Zachary Zhang, Thomas Petazzoni,
Lorenzo Pieralisi
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zachary Zhang <zhangzg@marvell.com>
commit 91a2968e245d6ba616db37001fa1a043078b1a65 upstream.
The PCIE I/O and MEM resource allocation mechanism is that root bus
goes through the following steps:
1. Check PCI bridges' range and computes I/O and Mem base/limits.
2. Sort all subordinate devices I/O and MEM resource requirements and
allocate the resources and writes/updates subordinate devices'
requirements to PCI bridges I/O and Mem MEM/limits registers.
Currently, PCI Aardvark driver only handles the second step and lacks
the first step, so there is an I/O and MEM resource allocation failure
when using a PCI switch. This commit fixes that by sizing bridges
before doing the resource allocation.
Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller
driver")
Signed-off-by: Zachary Zhang <zhangzg@marvell.com>
[Thomas: edit commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/controller/pci-aardvark.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -952,6 +952,7 @@ static int advk_pcie_probe(struct platfo
bus = bridge->bus;
+ pci_bus_size_bridges(bus);
pci_bus_assign_resources(bus);
list_for_each_entry(child, &bus->children, node)
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 17/22] PCI: Skip MPS logic for Virtual Functions (VFs)
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 16/22] PCI: aardvark: Size bridges before resources allocation Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 18/22] PCI: pciehp: Fix use-after-free on unplug Greg Kroah-Hartman
` (6 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Myron Stowe, Bjorn Helgaas,
Keith Busch, Sinan Kaya, Dongdong Liu, Jon Mason
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Myron Stowe <myron.stowe@redhat.com>
commit 3dbe97efe8bf450b183d6dee2305cbc032e6b8a4 upstream.
PCIe r4.0, sec 9.3.5.4, "Device Control Register", shows both
Max_Payload_Size (MPS) and Max_Read_request_Size (MRRS) to be 'RsvdP' for
VFs. Just prior to the table it states:
"PF and VF functionality is defined in Section 7.5.3.4 except where
noted in Table 9-16. For VF fields marked 'RsvdP', the PF setting
applies to the VF."
All of which implies that with respect to Max_Payload_Size Supported
(MPSS), MPS, and MRRS values, we should not be paying any attention to the
VF's fields, but rather only to the PF's. Only looking at the PF's fields
also logically makes sense as it's the sole physical interface to the PCIe
bus.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527
Fixes: 27d868b5e6cf ("PCI: Set MPS to match upstream bridge")
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org # 4.3+
Cc: Keith Busch <keith.busch@intel.com>
Cc: Sinan Kaya <okaya@kernel.org>
Cc: Dongdong Liu <liudongdong3@huawei.com>
Cc: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/probe.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1730,6 +1730,10 @@ static void pci_configure_mps(struct pci
if (!pci_is_pcie(dev) || !bridge || !pci_is_pcie(bridge))
return;
+ /* MPS and MRRS fields are of type 'RsvdP' for VFs, short-circuit out */
+ if (dev->is_virtfn)
+ return;
+
mps = pcie_get_mps(dev);
p_mps = pcie_get_mps(bridge);
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 18/22] PCI: pciehp: Fix use-after-free on unplug
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 17/22] PCI: Skip MPS logic for Virtual Functions (VFs) Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 19/22] PCI: pciehp: Fix unprotected list iteration in IRQ handler Greg Kroah-Hartman
` (5 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Lukas Wunner, Bjorn Helgaas
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukas Wunner <lukas@wunner.de>
commit 281e878eab191cce4259abbbf1a0322e3adae02c upstream.
When pciehp is unbound (e.g. on unplug of a Thunderbolt device), the
hotplug_slot struct is deregistered and thus freed before freeing the
IRQ. The IRQ handler and the work items it schedules print the slot
name referenced from the freed structure in various informational and
debug log messages, each time resulting in a quadruple dereference of
freed pointers (hotplug_slot -> pci_slot -> kobject -> name).
At best the slot name is logged as "(null)", at worst kernel memory is
exposed in logs or the driver crashes:
pciehp 0000:10:00.0:pcie204: Slot((null)): Card not present
An attacker may provoke the bug by unplugging multiple devices on a
Thunderbolt daisy chain at once. Unplugging can also be simulated by
powering down slots via sysfs. The bug is particularly easy to trigger
in poll mode.
It has been present since the driver's introduction in 2004:
https://git.kernel.org/tglx/history/c/c16b4b14d980
Fix by rearranging teardown such that the IRQ is freed first. Run the
work items queued by the IRQ handler to completion before freeing the
hotplug_slot struct by draining the work queue from the ->release_slot
callback which is invoked by pci_hp_deregister().
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org # v2.6.4
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/hotplug/pciehp.h | 1 +
drivers/pci/hotplug/pciehp_core.c | 7 +++++++
drivers/pci/hotplug/pciehp_hpc.c | 5 ++---
3 files changed, 10 insertions(+), 3 deletions(-)
--- a/drivers/pci/hotplug/pciehp.h
+++ b/drivers/pci/hotplug/pciehp.h
@@ -119,6 +119,7 @@ int pciehp_unconfigure_device(struct slo
void pciehp_queue_pushbutton_work(struct work_struct *work);
struct controller *pcie_init(struct pcie_device *dev);
int pcie_init_notification(struct controller *ctrl);
+void pcie_shutdown_notification(struct controller *ctrl);
int pciehp_enable_slot(struct slot *p_slot);
int pciehp_disable_slot(struct slot *p_slot);
void pcie_reenable_notification(struct controller *ctrl);
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -62,6 +62,12 @@ static int reset_slot(struct hotplug_slo
*/
static void release_slot(struct hotplug_slot *hotplug_slot)
{
+ struct slot *slot = hotplug_slot->private;
+
+ /* queued work needs hotplug_slot name */
+ cancel_delayed_work(&slot->work);
+ drain_workqueue(slot->wq);
+
kfree(hotplug_slot->ops);
kfree(hotplug_slot->info);
kfree(hotplug_slot);
@@ -264,6 +270,7 @@ static void pciehp_remove(struct pcie_de
{
struct controller *ctrl = get_service_data(dev);
+ pcie_shutdown_notification(ctrl);
cleanup_slot(ctrl);
pciehp_release_ctrl(ctrl);
}
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -765,7 +765,7 @@ int pcie_init_notification(struct contro
return 0;
}
-static void pcie_shutdown_notification(struct controller *ctrl)
+void pcie_shutdown_notification(struct controller *ctrl)
{
if (ctrl->notification_enabled) {
pcie_disable_notification(ctrl);
@@ -800,7 +800,7 @@ abort:
static void pcie_cleanup_slot(struct controller *ctrl)
{
struct slot *slot = ctrl->slot;
- cancel_delayed_work(&slot->work);
+
destroy_workqueue(slot->wq);
kfree(slot);
}
@@ -893,7 +893,6 @@ abort:
void pciehp_release_ctrl(struct controller *ctrl)
{
- pcie_shutdown_notification(ctrl);
pcie_cleanup_slot(ctrl);
kfree(ctrl);
}
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 19/22] PCI: pciehp: Fix unprotected list iteration in IRQ handler
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 18/22] PCI: pciehp: Fix use-after-free on unplug Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 20/22] i2c: core: ACPI: Properly set status byte to 0 for multi-byte writes Greg Kroah-Hartman
` (4 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Lukas Wunner, Bjorn Helgaas
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukas Wunner <lukas@wunner.de>
commit 1204e35bedf4e5015cda559ed8c84789a6dae24e upstream.
Commit b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug
events for a device") iterates over the devices on a hotplug port's
subordinate bus in pciehp's IRQ handler without acquiring pci_bus_sem.
It is thus possible for a user to cause a crash by concurrently
manipulating the device list, e.g. by disabling slot power via sysfs
on a different CPU or by initiating a remove/rescan via sysfs.
This can't be fixed by acquiring pci_bus_sem because it may sleep.
The simplest fix is to avoid the list iteration altogether and just
check the ignore_hotplug flag on the port itself. This works because
pci_ignore_hotplug() sets the flag both on the device as well as on its
parent bridge.
We do lose the ability to print the name of the device blocking hotplug
in the debug message, but that's probably bearable.
Fixes: b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/hotplug/pciehp_hpc.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -539,8 +539,6 @@ static irqreturn_t pciehp_isr(int irq, v
{
struct controller *ctrl = (struct controller *)dev_id;
struct pci_dev *pdev = ctrl_dev(ctrl);
- struct pci_bus *subordinate = pdev->subordinate;
- struct pci_dev *dev;
struct slot *slot = ctrl->slot;
u16 status, events;
u8 present;
@@ -588,14 +586,9 @@ static irqreturn_t pciehp_isr(int irq, v
wake_up(&ctrl->queue);
}
- if (subordinate) {
- list_for_each_entry(dev, &subordinate->devices, bus_list) {
- if (dev->ignore_hotplug) {
- ctrl_dbg(ctrl, "ignoring hotplug event %#06x (%s requested no hotplug)\n",
- events, pci_name(dev));
- return IRQ_HANDLED;
- }
- }
+ if (pdev->ignore_hotplug) {
+ ctrl_dbg(ctrl, "ignoring hotplug event %#06x\n", events);
+ return IRQ_HANDLED;
}
/* Check Attention Button Pressed */
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 20/22] i2c: core: ACPI: Properly set status byte to 0 for multi-byte writes
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 19/22] PCI: pciehp: Fix unprotected list iteration in IRQ handler Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 7:56 ` [PATCH 4.18 22/22] reiserfs: fix broken xattr handling (heap corruption, bad retval) Greg Kroah-Hartman
` (3 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans de Goede, Mika Westerberg, Wolfram Sang
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit c463a158cb6c5d9a85b7d894cd4f8116e8bd6be0 upstream.
acpi_gsb_i2c_write_bytes() returns i2c_transfer()'s return value, which
is the number of transfers executed on success, so 1.
The ACPI code expects us to store 0 in gsb->status for success, not 1.
Specifically this breaks the following code in the Thinkpad 8 DSDT:
ECWR = I2CW = ECWR /* \_SB_.I2C1.BAT0.ECWR */
If ((ECST == Zero))
{
ECRD = I2CR /* \_SB_.I2C1.I2CR */
}
Before this commit we set ECST to 1, causing the read to never happen
breaking battery monitoring on the Thinkpad 8.
This commit makes acpi_gsb_i2c_write_bytes() return 0 when i2c_transfer()
returns 1, so the single write transfer completed successfully, and
makes it return -EIO on for other (unexpected) return values >= 0.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/i2c-core-acpi.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -482,11 +482,16 @@ static int acpi_gsb_i2c_write_bytes(stru
msgs[0].buf = buffer;
ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
- if (ret < 0)
- dev_err(&client->adapter->dev, "i2c write failed\n");
kfree(buffer);
- return ret;
+
+ if (ret < 0) {
+ dev_err(&client->adapter->dev, "i2c write failed: %d\n", ret);
+ return ret;
+ }
+
+ /* 1 transfer must have completed successfully */
+ return (ret == 1) ? 0 : -EIO;
}
static acpi_status
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 4.18 22/22] reiserfs: fix broken xattr handling (heap corruption, bad retval)
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 20/22] i2c: core: ACPI: Properly set status byte to 0 for multi-byte writes Greg Kroah-Hartman
@ 2018-08-23 7:56 ` Greg Kroah-Hartman
2018-08-23 19:20 ` [PATCH 4.18 00/22] 4.18.5-stable review Shuah Khan
` (2 subsequent siblings)
20 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 7:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jann Horn, Jeff Mahoney,
Eric Biggers, Al Viro, Andrew Morton, Linus Torvalds
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn <jannh@google.com>
commit a13f085d111e90469faf2d9965eb39b11c114d7e upstream.
This fixes the following issues:
- When a buffer size is supplied to reiserfs_listxattr() such that each
individual name fits, but the concatenation of all names doesn't fit,
reiserfs_listxattr() overflows the supplied buffer. This leads to a
kernel heap overflow (verified using KASAN) followed by an out-of-bounds
usercopy and is therefore a security bug.
- When a buffer size is supplied to reiserfs_listxattr() such that a
name doesn't fit, -ERANGE should be returned. But reiserfs instead just
truncates the list of names; I have verified that if the only xattr on a
file has a longer name than the supplied buffer length, listxattr()
incorrectly returns zero.
With my patch applied, -ERANGE is returned in both cases and the memory
corruption doesn't happen anymore.
Credit for making me clean this code up a bit goes to Al Viro, who pointed
out that the ->actor calling convention is suboptimal and should be
changed.
Link: http://lkml.kernel.org/r/20180802151539.5373-1-jannh@google.com
Fixes: 48b32a3553a5 ("reiserfs: use generic xattr handlers")
Signed-off-by: Jann Horn <jannh@google.com>
Acked-by: Jeff Mahoney <jeffm@suse.com>
Cc: Eric Biggers <ebiggers@google.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/reiserfs/xattr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/reiserfs/xattr.c
+++ b/fs/reiserfs/xattr.c
@@ -792,8 +792,10 @@ static int listxattr_filler(struct dir_c
return 0;
size = namelen + 1;
if (b->buf) {
- if (size > b->size)
+ if (b->pos + size > b->size) {
+ b->pos = -ERANGE;
return -ERANGE;
+ }
memcpy(b->buf + b->pos, name, namelen);
b->buf[b->pos + namelen] = 0;
}
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 4.18 00/22] 4.18.5-stable review
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2018-08-23 7:56 ` [PATCH 4.18 22/22] reiserfs: fix broken xattr handling (heap corruption, bad retval) Greg Kroah-Hartman
@ 2018-08-23 19:20 ` Shuah Khan
2018-08-23 20:34 ` Greg Kroah-Hartman
2018-08-23 20:12 ` Guenter Roeck
2018-08-24 5:07 ` Naresh Kamboju
20 siblings, 1 reply; 25+ messages in thread
From: Shuah Khan @ 2018-08-23 19:20 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, lkft-triage,
stable, Shuah Khan
On 08/23/2018 01:56 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.5 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat Aug 25 07:47:43 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.5-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.18.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 4.18 00/22] 4.18.5-stable review
2018-08-23 19:20 ` [PATCH 4.18 00/22] 4.18.5-stable review Shuah Khan
@ 2018-08-23 20:34 ` Greg Kroah-Hartman
0 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 20:34 UTC (permalink / raw)
To: Shuah Khan
Cc: linux-kernel, torvalds, akpm, linux, patches, ben.hutchings,
lkft-triage, stable
On Thu, Aug 23, 2018 at 01:20:40PM -0600, Shuah Khan wrote:
> On 08/23/2018 01:56 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.5 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat Aug 25 07:47:43 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.5-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.18.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.
Thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4.18 00/22] 4.18.5-stable review
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2018-08-23 19:20 ` [PATCH 4.18 00/22] 4.18.5-stable review Shuah Khan
@ 2018-08-23 20:12 ` Guenter Roeck
2018-08-23 20:52 ` Greg Kroah-Hartman
2018-08-24 5:07 ` Naresh Kamboju
20 siblings, 1 reply; 25+ messages in thread
From: Guenter Roeck @ 2018-08-23 20:12 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
On Thu, Aug 23, 2018 at 09:56:26AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.5 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat Aug 25 07:47:43 UTC 2018.
> Anything received after that time might be too late.
>
Build results:
total: 134 pass: 134 fail: 0
Qemu test results:
total: 302 pass: 302 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 4.18 00/22] 4.18.5-stable review
2018-08-23 20:12 ` Guenter Roeck
@ 2018-08-23 20:52 ` Greg Kroah-Hartman
0 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-23 20:52 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
On Thu, Aug 23, 2018 at 01:12:22PM -0700, Guenter Roeck wrote:
> On Thu, Aug 23, 2018 at 09:56:26AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.5 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat Aug 25 07:47:43 UTC 2018.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 134 pass: 134 fail: 0
> Qemu test results:
> total: 302 pass: 302 fail: 0
>
> Details are available at http://kerneltests.org/builders.
Yeah! Thanks for testing all of these and reporting all of the issues.
greg k-h
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4.18 00/22] 4.18.5-stable review
2018-08-23 7:56 [PATCH 4.18 00/22] 4.18.5-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2018-08-23 20:12 ` Guenter Roeck
@ 2018-08-24 5:07 ` Naresh Kamboju
2018-08-24 6:18 ` Greg Kroah-Hartman
20 siblings, 1 reply; 25+ messages in thread
From: Naresh Kamboju @ 2018-08-24 5:07 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On 23 August 2018 at 13:26, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 4.18.5 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat Aug 25 07:47:43 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.5-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.18.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.
Summary
------------------------------------------------------------------------
kernel: 4.18.5-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.18.y
git commit: c456dc1ec5f92b9bab9cd6c3fa53ab7cc32c8d79
git describe: v4.18.4-23-gc456dc1ec5f9
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.4-23-gc456dc1ec5f9
No regressions (compared to build v4.18.3)
Ran 11322 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- x15 - arm
- x86_64
Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-cve-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 4.18 00/22] 4.18.5-stable review
2018-08-24 5:07 ` Naresh Kamboju
@ 2018-08-24 6:18 ` Greg Kroah-Hartman
0 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-24 6:18 UTC (permalink / raw)
To: Naresh Kamboju
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On Fri, Aug 24, 2018 at 10:37:13AM +0530, Naresh Kamboju wrote:
> On 23 August 2018 at 13:26, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > This is the start of the stable review cycle for the 4.18.5 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat Aug 25 07:47:43 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.5-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.18.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.
Great, thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 25+ messages in thread