Hi Greg,
upstream commit 1572e45a924f ("perf/core: Fix the perf_cpu_time_max_percent check")
fixes CVE-2017-18255. Please apply to v4.9.y and older.
The patch applies cleanly to v4.9.y and v4.4.y; I didn't check older kernels.
More recent kernels are not affected.
Thanks,
Guenter
On Wed, May 2, 2018 at 1:49 AM <gregkh(a)linuxfoundation.org> wrote:
> This is a note to let you know that I've just added the patch titled
> PCI: endpoint: Fix kernel panic after put_device()
> to the 4.14-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
> The filename of the patch is:
> pci-endpoint-fix-kernel-panic-after-put_device.patch
> and it can be found in the queue-4.14 subdirectory.
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
This patch is the 2nd one of a series of patches. If you want to add it
to the stable tree without the first patch, you must add a
+ kfree(func_name);
before returning from the function.
The upstream commit of the first patch is
36cc14ac14c0d49d33820a82dab52a7edc802fef PCI: endpoint: Simplify name
allocation for EPF device
Kind regards,
Rolf
> From foo@baz Tue May 1 16:18:20 PDT 2018
> From: Rolf Evers-Fischer <rolf.evers.fischer(a)aptiv.com>
> Date: Wed, 28 Feb 2018 18:32:19 +0100
> Subject: PCI: endpoint: Fix kernel panic after put_device()
> From: Rolf Evers-Fischer <rolf.evers.fischer(a)aptiv.com>
> [ Upstream commit 9eef6a5c3b0bf90eb292d462ea267bcb6ad1c334 ]
> 'put_device()' calls the relase function 'pci_epf_dev_release()',
> which already frees 'epf->name' and 'epf'.
> Therefore we must not free them again after 'put_device()'.
> Fixes: 5e8cb4033807 ("PCI: endpoint: Add EP core layer to enable EP
> controller and EP functions")
> Signed-off-by: Rolf Evers-Fischer <rolf.evers.fischer(a)aptiv.com>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
> Acked-by: Kishon Vijay Abraham I <kishon(a)ti.com>
> Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com>
> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
> ---
> drivers/pci/endpoint/pci-epf-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> --- a/drivers/pci/endpoint/pci-epf-core.c
> +++ b/drivers/pci/endpoint/pci-epf-core.c
> @@ -254,7 +254,7 @@ struct pci_epf *pci_epf_create(const cha
> put_dev:
> put_device(dev);
> - kfree(epf->name);
> + return ERR_PTR(ret);
> free_func_name:
> kfree(func_name);
> Patches currently in stable-queue which might be from
> rolf.evers.fischer(a)aptiv.com are
> queue-4.14/pci-endpoint-fix-kernel-panic-after-put_device.patch
On Tue, May 1, 2018 at 4:52 PM <gregkh(a)linuxfoundation.org> wrote:
> This is a note to let you know that I've just added the patch titled
> mm, mlock, vmscan: no more skipping pagevecs
> to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
> The filename of the patch is:
> mm-mlock-vmscan-no-more-skipping-pagevecs.patch
> and it can be found in the queue-4.14 subdirectory.
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
I would advise not to include this patch in the previous stable trees. This
patch does not fix any critical bug and for some very specific
microbenchmarks on very large machines, it has shown performance
regression. So, I don't think it is worth the risk.
> From foo@baz Tue May 1 16:18:19 PDT 2018
> From: Shakeel Butt <shakeelb(a)google.com>
> Date: Wed, 21 Feb 2018 14:45:28 -0800
> Subject: mm, mlock, vmscan: no more skipping pagevecs
> From: Shakeel Butt <shakeelb(a)google.com>
> [ Upstream commit 9c4e6b1a7027f102990c0395296015a812525f4d ]
> When a thread mlocks an address space backed either by file pages which
> are currently not present in memory or swapped out anon pages (not in
> swapcache), a new page is allocated and added to the local pagevec
> (lru_add_pvec), I/O is triggered and the thread then sleeps on the page.
> On I/O completion, the thread can wake on a different CPU, the mlock
> syscall will then sets the PageMlocked() bit of the page but will not be
> able to put that page in unevictable LRU as the page is on the pagevec
> of a different CPU. Even on drain, that page will go to evictable LRU
> because the PageMlocked() bit is not checked on pagevec drain.
> The page will eventually go to right LRU on reclaim but the LRU stats
> will remain skewed for a long time.
> This patch puts all the pages, even unevictable, to the pagevecs and on
> the drain, the pages will be added on their LRUs correctly by checking
> their evictability. This resolves the mlocked pages on pagevec of other
> CPUs issue because when those pagevecs will be drained, the mlocked file
> pages will go to unevictable LRU. Also this makes the race with munlock
> easier to resolve because the pagevec drains happen in LRU lock.
> However there is still one place which makes a page evictable and does
> PageLRU check on that page without LRU lock and needs special attention.
> TestClearPageMlocked() and isolate_lru_page() in clear_page_mlock().
> #0: __pagevec_lru_add_fn #1: clear_page_mlock
> SetPageLRU() if (!TestClearPageMlocked())
> return
> smp_mb() // <--required
> // inside does PageLRU
> if (!PageMlocked()) if (isolate_lru_page())
> move to evictable LRU putback_lru_page()
> else
> move to unevictable LRU
> In '#1', TestClearPageMlocked() provides full memory barrier semantics
> and thus the PageLRU check (inside isolate_lru_page) can not be
> reordered before it.
> In '#0', without explicit memory barrier, the PageMlocked() check can be
> reordered before SetPageLRU(). If that happens, '#0' can put a page in
> unevictable LRU and '#1' might have just cleared the Mlocked bit of that
> page but fails to isolate as PageLRU fails as '#0' still hasn't set
> PageLRU bit of that page. That page will be stranded on the unevictable
> LRU.
> There is one (good) side effect though. Without this patch, the pages
> allocated for System V shared memory segment are added to evictable LRUs
> even after shmctl(SHM_LOCK) on that segment. This patch will correctly
> put such pages to unevictable LRU.
> Link: http://lkml.kernel.org/r/20171121211241.18877-1-shakeelb@google.com
> Signed-off-by: Shakeel Butt <shakeelb(a)google.com>
> Acked-by: Vlastimil Babka <vbabka(a)suse.cz>
> Cc: Jérôme Glisse <jglisse(a)redhat.com>
> Cc: Huang Ying <ying.huang(a)intel.com>
> Cc: Tim Chen <tim.c.chen(a)linux.intel.com>
> Cc: Michal Hocko <mhocko(a)kernel.org>
> Cc: Greg Thelen <gthelen(a)google.com>
> Cc: Johannes Weiner <hannes(a)cmpxchg.org>
> Cc: Balbir Singh <bsingharora(a)gmail.com>
> Cc: Minchan Kim <minchan(a)kernel.org>
> Cc: Shaohua Li <shli(a)fb.com>
> Cc: Jan Kara <jack(a)suse.cz>
> Cc: Nicholas Piggin <npiggin(a)gmail.com>
> Cc: Dan Williams <dan.j.williams(a)intel.com>
> Cc: Mel Gorman <mgorman(a)suse.de>
> Cc: Hugh Dickins <hughd(a)google.com>
> Cc: Vlastimil Babka <vbabka(a)suse.cz>
> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
> ---
> include/linux/swap.h | 2 -
> mm/mlock.c | 6 +++
> mm/swap.c | 82
+++++++++++++++++++++++++++++----------------------
> mm/vmscan.c | 59 ------------------------------------
> 4 files changed, 54 insertions(+), 95 deletions(-)
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -326,8 +326,6 @@ extern void deactivate_file_page(struct
> extern void mark_page_lazyfree(struct page *page);
> extern void swap_setup(void);
> -extern void add_page_to_unevictable_list(struct page *page);
> -
> extern void lru_cache_add_active_or_unevictable(struct page *page,
> struct vm_area_struct
*vma);
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -64,6 +64,12 @@ void clear_page_mlock(struct page *page)
> mod_zone_page_state(page_zone(page), NR_MLOCK,
> -hpage_nr_pages(page));
> count_vm_event(UNEVICTABLE_PGCLEARED);
> + /*
> + * The previous TestClearPageMlocked() corresponds to the smp_mb()
> + * in __pagevec_lru_add_fn().
> + *
> + * See __pagevec_lru_add_fn for more explanation.
> + */
> if (!isolate_lru_page(page)) {
> putback_lru_page(page);
> } else {
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -446,30 +446,6 @@ void lru_cache_add(struct page *page)
> }
> /**
> - * add_page_to_unevictable_list - add a page to the unevictable list
> - * @page: the page to be added to the unevictable list
> - *
> - * Add page directly to its zone's unevictable list. To avoid races with
> - * tasks that might be making the page evictable, through eg. munlock,
> - * munmap or exit, while it's not on the lru, we want to add the page
> - * while it's locked or otherwise "invisible" to other tasks. This is
> - * difficult to do when using the pagevec cache, so bypass that.
> - */
> -void add_page_to_unevictable_list(struct page *page)
> -{
> - struct pglist_data *pgdat = page_pgdat(page);
> - struct lruvec *lruvec;
> -
> - spin_lock_irq(&pgdat->lru_lock);
> - lruvec = mem_cgroup_page_lruvec(page, pgdat);
> - ClearPageActive(page);
> - SetPageUnevictable(page);
> - SetPageLRU(page);
> - add_page_to_lru_list(page, lruvec, LRU_UNEVICTABLE);
> - spin_unlock_irq(&pgdat->lru_lock);
> -}
> -
> -/**
> * lru_cache_add_active_or_unevictable
> * @page: the page to be added to LRU
> * @vma: vma in which page is mapped for determining reclaimability
> @@ -484,13 +460,9 @@ void lru_cache_add_active_or_unevictable
> {
> VM_BUG_ON_PAGE(PageLRU(page), page);
> - if (likely((vma->vm_flags & (VM_LOCKED | VM_SPECIAL)) !=
VM_LOCKED)) {
> + if (likely((vma->vm_flags & (VM_LOCKED | VM_SPECIAL)) !=
VM_LOCKED))
> SetPageActive(page);
> - lru_cache_add(page);
> - return;
> - }
> -
> - if (!TestSetPageMlocked(page)) {
> + else if (!TestSetPageMlocked(page)) {
> /*
> * We use the irq-unsafe __mod_zone_page_stat because this
> * counter is not modified from interrupt context, and
the pte
> @@ -500,7 +472,7 @@ void lru_cache_add_active_or_unevictable
> hpage_nr_pages(page));
> count_vm_event(UNEVICTABLE_PGMLOCKED);
> }
> - add_page_to_unevictable_list(page);
> + lru_cache_add(page);
> }
> /*
> @@ -883,15 +855,55 @@ void lru_add_page_tail(struct page *page
> static void __pagevec_lru_add_fn(struct page *page, struct lruvec
*lruvec,
> void *arg)
> {
> - int file = page_is_file_cache(page);
> - int active = PageActive(page);
> - enum lru_list lru = page_lru(page);
> + enum lru_list lru;
> + int was_unevictable = TestClearPageUnevictable(page);
> VM_BUG_ON_PAGE(PageLRU(page), page);
> SetPageLRU(page);
> + /*
> + * Page becomes evictable in two ways:
> + * 1) Within LRU lock [munlock_vma_pages() and
__munlock_pagevec()].
> + * 2) Before acquiring LRU lock to put the page to correct LRU
and then
> + * a) do PageLRU check with lock [check_move_unevictable_pages]
> + * b) do PageLRU check before lock [clear_page_mlock]
> + *
> + * (1) & (2a) are ok as LRU lock will serialize them. For (2b),
we need
> + * following strict ordering:
> + *
> + * #0: __pagevec_lru_add_fn #1: clear_page_mlock
> + *
> + * SetPageLRU() TestClearPageMlocked()
> + * smp_mb() // explicit ordering // above provides strict
> + * // ordering
> + * PageMlocked() PageLRU()
> + *
> + *
> + * if '#1' does not observe setting of PG_lru by '#0' and fails
> + * isolation, the explicit barrier will make sure that
page_evictable
> + * check will put the page in correct LRU. Without smp_mb(),
SetPageLRU
> + * can be reordered after PageMlocked check and can make '#1' to
fail
> + * the isolation of the page whose Mlocked bit is cleared (#0 is
also
> + * looking at the same page) and the evictable page will be
stranded
> + * in an unevictable LRU.
> + */
> + smp_mb();
> +
> + if (page_evictable(page)) {
> + lru = page_lru(page);
> + update_page_reclaim_stat(lruvec, page_is_file_cache(page),
> + PageActive(page));
> + if (was_unevictable)
> + count_vm_event(UNEVICTABLE_PGRESCUED);
> + } else {
> + lru = LRU_UNEVICTABLE;
> + ClearPageActive(page);
> + SetPageUnevictable(page);
> + if (!was_unevictable)
> + count_vm_event(UNEVICTABLE_PGCULLED);
> + }
> +
> add_page_to_lru_list(page, lruvec, lru);
> - update_page_reclaim_stat(lruvec, file, active);
> trace_mm_lru_insertion(page, lru);
> }
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -790,64 +790,7 @@ int remove_mapping(struct address_space
> */
> void putback_lru_page(struct page *page)
> {
> - bool is_unevictable;
> - int was_unevictable = PageUnevictable(page);
> -
> - VM_BUG_ON_PAGE(PageLRU(page), page);
> -
> -redo:
> - ClearPageUnevictable(page);
> -
> - if (page_evictable(page)) {
> - /*
> - * For evictable pages, we can use the cache.
> - * In event of a race, worst case is we end up with an
> - * unevictable page on [in]active list.
> - * We know how to handle that.
> - */
> - is_unevictable = false;
> - lru_cache_add(page);
> - } else {
> - /*
> - * Put unevictable pages directly on zone's unevictable
> - * list.
> - */
> - is_unevictable = true;
> - add_page_to_unevictable_list(page);
> - /*
> - * When racing with an mlock or AS_UNEVICTABLE clearing
> - * (page is unlocked) make sure that if the other thread
> - * does not observe our setting of PG_lru and fails
> - * isolation/check_move_unevictable_pages,
> - * we see PG_mlocked/AS_UNEVICTABLE cleared below and move
> - * the page back to the evictable list.
> - *
> - * The other side is TestClearPageMlocked() or
shmem_lock().
> - */
> - smp_mb();
> - }
> -
> - /*
> - * page's status can change while we move it among lru. If an
evictable
> - * page is on unevictable list, it never be freed. To avoid that,
> - * check after we added it to the list, again.
> - */
> - if (is_unevictable && page_evictable(page)) {
> - if (!isolate_lru_page(page)) {
> - put_page(page);
> - goto redo;
> - }
> - /* This means someone else dropped this page from LRU
> - * So, it will be freed or putback to LRU again. There is
> - * nothing to do here.
> - */
> - }
> -
> - if (was_unevictable && !is_unevictable)
> - count_vm_event(UNEVICTABLE_PGRESCUED);
> - else if (!was_unevictable && is_unevictable)
> - count_vm_event(UNEVICTABLE_PGCULLED);
> -
> + lru_cache_add(page);
> put_page(page); /* drop ref from isolate */
> }
> Patches currently in stable-queue which might be from shakeelb(a)google.com
are
> queue-4.14/mm-slab-memcg_link-the-slab-s-kmem_cache.patch
> queue-4.14/mm-mlock-vmscan-no-more-skipping-pagevecs.patch
Latest binutils release (2.29.1) will no longer allow proper computation
of GDT entries on 32-bits, with warning:
arch/x86/xen/xen-pvh.S: Assembler messages:
arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not between 0 and 31)
arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (40 is not between 0 and 31)
arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not between 0 and 31)
arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (32 is not between 0 and 31)
arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (40 is not between 0 and 31)
arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (32 is not between 0 and 31)
Use explicit value of the entry instead of using GDT_ENTRY() macro.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Cc: stable(a)vger.kernel.org
---
arch/x86/xen/xen-pvh.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
index e1a5fbe..934f7d4 100644
--- a/arch/x86/xen/xen-pvh.S
+++ b/arch/x86/xen/xen-pvh.S
@@ -145,11 +145,11 @@ gdt_start:
.quad 0x0000000000000000 /* NULL descriptor */
.quad 0x0000000000000000 /* reserved */
#ifdef CONFIG_X86_64
- .quad GDT_ENTRY(0xa09a, 0, 0xfffff) /* __KERNEL_CS */
+ .quad 0x00af9a000000ffff /* __BOOT_CS */
#else
- .quad GDT_ENTRY(0xc09a, 0, 0xfffff) /* __KERNEL_CS */
+ .quad 0x00cf9a000000ffff /* __BOOT_CS */
#endif
- .quad GDT_ENTRY(0xc092, 0, 0xfffff) /* __KERNEL_DS */
+ .quad 0x00cf92000000ffff /* __BOOT_DS */
gdt_end:
.balign 4
--
2.9.3
Patches in original Xen Security Advisory 155 cared only about backend drivers
while leaving frontend patches to be "developed and released (publicly) after
the embargo date". This is said series.
Marek Marczykowski-Górecki (6):
xen: Add RING_COPY_RESPONSE()
xen-netfront: copy response out of shared buffer before accessing it
xen-netfront: do not use data already exposed to backend
xen-netfront: add range check for Tx response id
xen-blkfront: make local copy of response before using it
xen-blkfront: prepare request locally, only then put it on the shared ring
drivers/block/xen-blkfront.c | 110 ++++++++++++++++++---------------
drivers/net/xen-netfront.c | 61 +++++++++---------
include/xen/interface/io/ring.h | 14 ++++-
3 files changed, 106 insertions(+), 79 deletions(-)
base-commit: 6d08b06e67cd117f6992c46611dfb4ce267cd71e
--
git-series 0.9.1