- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch "ipc: msg, make msgrcv work with LONG_MIN" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipc: msg, make msgrcv work with LONG_MIN to the 4.4-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: ipc-msg-make-msgrcv-work-with-long_min.patch and it can be found in the queue-4.4 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. >From 999898355e08ae3b92dfd0a08db706e0c6703d30 Mon Sep 17 00:00:00 2001 From: Jiri Slaby <jslaby(a)suse.cz> Date: Wed, 14 Dec 2016 15:06:07 -0800 Subject: ipc: msg, make msgrcv work with LONG_MIN From: Jiri Slaby <jslaby(a)suse.cz> commit 999898355e08ae3b92dfd0a08db706e0c6703d30 upstream. When LONG_MIN is passed to msgrcv, one would expect to recieve any message. But convert_mode does *msgtyp = -*msgtyp and -LONG_MIN is undefined. In particular, with my gcc -LONG_MIN produces -LONG_MIN again. So handle this case properly by assigning LONG_MAX to *msgtyp if LONG_MIN was specified as msgtyp to msgrcv. This code: long msg[] = { 100, 200 }; int m = msgget(IPC_PRIVATE, IPC_CREAT | 0644); msgsnd(m, &msg, sizeof(msg), 0); msgrcv(m, &msg, sizeof(msg), LONG_MIN, 0); produces currently nothing: msgget(IPC_PRIVATE, IPC_CREAT|0644) = 65538 msgsnd(65538, {100, "\310\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16, 0) = 0 msgrcv(65538, ... Except a UBSAN warning: UBSAN: Undefined behaviour in ipc/msg.c:745:13 negation of -9223372036854775808 cannot be represented in type 'long int': With the patch, I see what I expect: msgget(IPC_PRIVATE, IPC_CREAT|0644) = 0 msgsnd(0, {100, "\310\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16, 0) = 0 msgrcv(0, {100, "\310\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16, -9223372036854775808, 0) = 16 Link: http://lkml.kernel.org/r/20161024082633.10148-1-jslaby@suse.cz Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Manfred Spraul <manfred(a)colorfullife.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- ipc/msg.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/ipc/msg.c +++ b/ipc/msg.c @@ -742,7 +742,10 @@ static inline int convert_mode(long *msg if (*msgtyp == 0) return SEARCH_ANY; if (*msgtyp < 0) { - *msgtyp = -*msgtyp; + if (*msgtyp == LONG_MIN) /* -LONG_MIN is undefined */ + *msgtyp = LONG_MAX; + else + *msgtyp = -*msgtyp; return SEARCH_LESSEQUAL; } if (msgflg & MSG_EXCEPT) Patches currently in stable-queue which might be from jslaby(a)suse.cz are queue-4.4/ipc-msg-make-msgrcv-work-with-long_min.patch queue-4.4/fs-fcntl-f_setown-avoid-undefined-behaviour.patch queue-4.4/pm-sleep-declare-__tracedata-symbols-as-char-rather-than-char.patch queue-4.4/x86-cpu-intel-introduce-macros-for-intel-family-numbers.patch queue-4.4/x86-retpoline-fill-rsb-on-context-switch-for-affected-cpus.patch queue-4.4/acpi-scan-prefer-devices-without-_hid-_cid-for-_adr-matching.patch queue-4.4/time-avoid-undefined-behaviour-in-ktime_add_safe.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] Patch "hwpoison, memcg: forcibly uncharge LRU pages" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hwpoison, memcg: forcibly uncharge LRU pages to the 4.4-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: hwpoison-memcg-forcibly-uncharge-lru-pages.patch and it can be found in the queue-4.4 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. >From 18365225f0440d09708ad9daade2ec11275c3df9 Mon Sep 17 00:00:00 2001 From: Michal Hocko <mhocko(a)suse.com> Date: Fri, 12 May 2017 15:46:26 -0700 Subject: hwpoison, memcg: forcibly uncharge LRU pages From: Michal Hocko <mhocko(a)suse.com> commit 18365225f0440d09708ad9daade2ec11275c3df9 upstream. Laurent Dufour has noticed that hwpoinsoned pages are kept charged. In his particular case he has hit a bad_page("page still charged to cgroup") when onlining a hwpoison page. While this looks like something that shouldn't happen in the first place because onlining hwpages and returning them to the page allocator makes only little sense it shows a real problem. hwpoison pages do not get freed usually so we do not uncharge them (at least not since commit 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API")). Each charge pins memcg (since e8ea14cc6ead ("mm: memcontrol: take a css reference for each charged page")) as well and so the mem_cgroup and the associated state will never go away. Fix this leak by forcibly uncharging a LRU hwpoisoned page in delete_from_lru_cache(). We also have to tweak uncharge_list because it cannot rely on zero ref count for these pages. [akpm(a)linux-foundation.org: coding-style fixes] Fixes: 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API") Link: http://lkml.kernel.org/r/20170502185507.GB19165@dhcp22.suse.cz Signed-off-by: Michal Hocko <mhocko(a)suse.com> Reported-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com> Tested-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com> Reviewed-by: Balbir Singh <bsingharora(a)gmail.com> Reviewed-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/memcontrol.c | 2 +- mm/memory-failure.c | 7 +++++++ 2 files changed, 8 insertions(+), 1 deletion(-) --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -5576,7 +5576,7 @@ static void uncharge_list(struct list_he next = page->lru.next; VM_BUG_ON_PAGE(PageLRU(page), page); - VM_BUG_ON_PAGE(page_count(page), page); + VM_BUG_ON_PAGE(!PageHWPoison(page) && page_count(page), page); if (!page->mem_cgroup) continue; --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -539,6 +539,13 @@ static int delete_from_lru_cache(struct */ ClearPageActive(p); ClearPageUnevictable(p); + + /* + * Poisoned page might never drop its ref count to 0 so we have + * to uncharge it manually from its memcg. + */ + mem_cgroup_uncharge(p); + /* * drop the page count elevated by isolate_lru_page() */ Patches currently in stable-queue which might be from mhocko(a)suse.com are queue-4.4/fs-select-add-vmalloc-fallback-for-select-2.patch queue-4.4/hwpoison-memcg-forcibly-uncharge-lru-pages.patch queue-4.4/mm-mmap.c-do-not-blow-on-prot_none-map_fixed-holes-in-the-stack.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] Patch "fs/fcntl: f_setown, avoid undefined behaviour" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fs/fcntl: f_setown, avoid undefined behaviour to the 4.4-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: fs-fcntl-f_setown-avoid-undefined-behaviour.patch and it can be found in the queue-4.4 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. >From fc3dc67471461c0efcb1ed22fb7595121d65fad9 Mon Sep 17 00:00:00 2001 From: Jiri Slaby <jslaby(a)suse.cz> Date: Tue, 13 Jun 2017 13:35:51 +0200 Subject: fs/fcntl: f_setown, avoid undefined behaviour From: Jiri Slaby <jslaby(a)suse.cz> commit fc3dc67471461c0efcb1ed22fb7595121d65fad9 upstream. fcntl(0, F_SETOWN, 0x80000000) triggers: UBSAN: Undefined behaviour in fs/fcntl.c:118:7 negation of -2147483648 cannot be represented in type 'int': CPU: 1 PID: 18261 Comm: syz-executor Not tainted 4.8.1-0-syzkaller #1 ... Call Trace: ... [<ffffffffad8f0868>] ? f_setown+0x1d8/0x200 [<ffffffffad8f19a9>] ? SyS_fcntl+0x999/0xf30 [<ffffffffaed1fb00>] ? entry_SYSCALL_64_fastpath+0x23/0xc1 Fix that by checking the arg parameter properly (against INT_MAX) before "who = -who". And return immediatelly with -EINVAL in case it is wrong. Note that according to POSIX we can return EINVAL: http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html [EINVAL] The cmd argument is F_SETOWN and the value of the argument is not valid as a process or process group identifier. [v2] returns an error, v1 used to fail silently [v3] implement proper check for the bad value INT_MIN Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Cc: Jeff Layton <jlayton(a)poochiereds.net> Cc: "J. Bruce Fields" <bfields(a)fieldses.org> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: linux-fsdevel(a)vger.kernel.org Signed-off-by: Jeff Layton <jlayton(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/fcntl.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/fs/fcntl.c +++ b/fs/fcntl.c @@ -113,6 +113,10 @@ void f_setown(struct file *filp, unsigne int who = arg; type = PIDTYPE_PID; if (who < 0) { + /* avoid overflow below */ + if (who == INT_MIN) + return; + type = PIDTYPE_PGID; who = -who; } Patches currently in stable-queue which might be from jslaby(a)suse.cz are queue-4.4/ipc-msg-make-msgrcv-work-with-long_min.patch queue-4.4/fs-fcntl-f_setown-avoid-undefined-behaviour.patch queue-4.4/pm-sleep-declare-__tracedata-symbols-as-char-rather-than-char.patch queue-4.4/x86-cpu-intel-introduce-macros-for-intel-family-numbers.patch queue-4.4/x86-retpoline-fill-rsb-on-context-switch-for-affected-cpus.patch queue-4.4/acpi-scan-prefer-devices-without-_hid-_cid-for-_adr-matching.patch queue-4.4/time-avoid-undefined-behaviour-in-ktime_add_safe.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] Patch "ext2: Don't clear SGID when inheriting ACLs" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ext2: Don't clear SGID when inheriting ACLs to the 4.4-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: ext2-don-t-clear-sgid-when-inheriting-acls.patch and it can be found in the queue-4.4 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. >From a992f2d38e4ce17b8c7d1f7f67b2de0eebdea069 Mon Sep 17 00:00:00 2001 From: Jan Kara <jack(a)suse.cz> Date: Wed, 21 Jun 2017 14:34:15 +0200 Subject: ext2: Don't clear SGID when inheriting ACLs From: Jan Kara <jack(a)suse.cz> commit a992f2d38e4ce17b8c7d1f7f67b2de0eebdea069 upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by creating __ext2_set_acl() function that does not call posix_acl_update_mode() and use it when inheriting ACLs. That prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef CC: stable(a)vger.kernel.org CC: linux-ext4(a)vger.kernel.org Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/ext2/acl.c | 36 ++++++++++++++++++++++-------------- 1 file changed, 22 insertions(+), 14 deletions(-) --- a/fs/ext2/acl.c +++ b/fs/ext2/acl.c @@ -178,11 +178,8 @@ ext2_get_acl(struct inode *inode, int ty return acl; } -/* - * inode->i_mutex: down - */ -int -ext2_set_acl(struct inode *inode, struct posix_acl *acl, int type) +static int +__ext2_set_acl(struct inode *inode, struct posix_acl *acl, int type) { int name_index; void *value = NULL; @@ -192,13 +189,6 @@ ext2_set_acl(struct inode *inode, struct switch(type) { case ACL_TYPE_ACCESS: name_index = EXT2_XATTR_INDEX_POSIX_ACL_ACCESS; - if (acl) { - error = posix_acl_update_mode(inode, &inode->i_mode, &acl); - if (error) - return error; - inode->i_ctime = CURRENT_TIME_SEC; - mark_inode_dirty(inode); - } break; case ACL_TYPE_DEFAULT: @@ -225,6 +215,24 @@ ext2_set_acl(struct inode *inode, struct } /* + * inode->i_mutex: down + */ +int +ext2_set_acl(struct inode *inode, struct posix_acl *acl, int type) +{ + int error; + + if (type == ACL_TYPE_ACCESS && acl) { + error = posix_acl_update_mode(inode, &inode->i_mode, &acl); + if (error) + return error; + inode->i_ctime = CURRENT_TIME_SEC; + mark_inode_dirty(inode); + } + return __ext2_set_acl(inode, acl, type); +} + +/* * Initialize the ACLs of a new inode. Called from ext2_new_inode. * * dir->i_mutex: down @@ -241,12 +249,12 @@ ext2_init_acl(struct inode *inode, struc return error; if (default_acl) { - error = ext2_set_acl(inode, default_acl, ACL_TYPE_DEFAULT); + error = __ext2_set_acl(inode, default_acl, ACL_TYPE_DEFAULT); posix_acl_release(default_acl); } if (acl) { if (!error) - error = ext2_set_acl(inode, acl, ACL_TYPE_ACCESS); + error = __ext2_set_acl(inode, acl, ACL_TYPE_ACCESS); posix_acl_release(acl); } return error; Patches currently in stable-queue which might be from jack(a)suse.cz are queue-4.4/reiserfs-don-t-preallocate-blocks-for-extended-attributes.patch queue-4.4/ext2-don-t-clear-sgid-when-inheriting-acls.patch queue-4.4/reiserfs-fix-race-in-prealloc-discard.patch queue-4.4/reiserfs-don-t-clear-sgid-when-inheriting-acls.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] Patch "cma: fix calculation of aligned offset" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cma: fix calculation of aligned offset to the 4.4-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: cma-fix-calculation-of-aligned-offset.patch and it can be found in the queue-4.4 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. >From e048cb32f69038aa1c8f11e5c1b331be4181659d Mon Sep 17 00:00:00 2001 From: Doug Berger <opendmb(a)gmail.com> Date: Mon, 10 Jul 2017 15:49:44 -0700 Subject: cma: fix calculation of aligned offset From: Doug Berger <opendmb(a)gmail.com> commit e048cb32f69038aa1c8f11e5c1b331be4181659d upstream. The align_offset parameter is used by bitmap_find_next_zero_area_off() to represent the offset of map's base from the previous alignment boundary; the function ensures that the returned index, plus the align_offset, honors the specified align_mask. The logic introduced by commit b5be83e308f7 ("mm: cma: align to physical address, not CMA region position") has the cma driver calculate the offset to the *next* alignment boundary. In most cases, the base alignment is greater than that specified when making allocations, resulting in a zero offset whether we align up or down. In the example given with the commit, the base alignment (8MB) was half the requested alignment (16MB) so the math also happened to work since the offset is 8MB in both directions. However, when requesting allocations with an alignment greater than twice that of the base, the returned index would not be correctly aligned. Also, the align_order arguments of cma_bitmap_aligned_mask() and cma_bitmap_aligned_offset() should not be negative so the argument type was made unsigned. Fixes: b5be83e308f7 ("mm: cma: align to physical address, not CMA region position") Link: http://lkml.kernel.org/r/20170628170742.2895-1-opendmb@gmail.com Signed-off-by: Angus Clark <angus(a)angusclark.org> Signed-off-by: Doug Berger <opendmb(a)gmail.com> Acked-by: Gregory Fong <gregory.0xf0(a)gmail.com> Cc: Doug Berger <opendmb(a)gmail.com> Cc: Angus Clark <angus(a)angusclark.org> Cc: Laura Abbott <labbott(a)redhat.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Shiraz Hashim <shashim(a)codeaurora.org> Cc: Jaewon Kim <jaewon31.kim(a)samsung.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/cma.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) --- a/mm/cma.c +++ b/mm/cma.c @@ -54,7 +54,7 @@ unsigned long cma_get_size(const struct } static unsigned long cma_bitmap_aligned_mask(const struct cma *cma, - int align_order) + unsigned int align_order) { if (align_order <= cma->order_per_bit) return 0; @@ -62,17 +62,14 @@ static unsigned long cma_bitmap_aligned_ } /* - * Find a PFN aligned to the specified order and return an offset represented in - * order_per_bits. + * Find the offset of the base PFN from the specified align_order. + * The value returned is represented in order_per_bits. */ static unsigned long cma_bitmap_aligned_offset(const struct cma *cma, - int align_order) + unsigned int align_order) { - if (align_order <= cma->order_per_bit) - return 0; - - return (ALIGN(cma->base_pfn, (1UL << align_order)) - - cma->base_pfn) >> cma->order_per_bit; + return (cma->base_pfn & ((1UL << align_order) - 1)) + >> cma->order_per_bit; } static unsigned long cma_bitmap_pages_to_bits(const struct cma *cma, Patches currently in stable-queue which might be from opendmb(a)gmail.com are queue-4.4/cma-fix-calculation-of-aligned-offset.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] Patch "ACPICA: Namespace: fix operand cache leak" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPICA: Namespace: fix operand cache leak to the 4.4-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: acpica-namespace-fix-operand-cache-leak.patch and it can be found in the queue-4.4 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. >From 3b2d69114fefa474fca542e51119036dceb4aa6f Mon Sep 17 00:00:00 2001 From: Seunghun Han <kkamagui(a)gmail.com> Date: Wed, 26 Apr 2017 16:18:08 +0800 Subject: ACPICA: Namespace: fix operand cache leak From: Seunghun Han <kkamagui(a)gmail.com> commit 3b2d69114fefa474fca542e51119036dceb4aa6f upstream. ACPICA commit a23325b2e583556eae88ed3f764e457786bf4df6 I found some ACPI operand cache leaks in ACPI early abort cases. Boot log of ACPI operand cache leak is as follows: >[ 0.174332] ACPI: Added _OSI(Module Device) >[ 0.175504] ACPI: Added _OSI(Processor Device) >[ 0.176010] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.177032] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.178284] ACPI: SCI (IRQ16705) allocation failed >[ 0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (20160930/evevent-131) >[ 0.180008] ACPI: Unable to start the ACPI Interpreter >[ 0.181125] ACPI Error: Could not remove SCI handler (20160930/evmisc-281) >[ 0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2 >[ 0.186820] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.188000] Call Trace: >[ 0.188000] ? dump_stack+0x5c/0x7d >[ 0.188000] ? kmem_cache_destroy+0x224/0x230 >[ 0.188000] ? acpi_sleep_proc_init+0x22/0x22 >[ 0.188000] ? acpi_os_delete_cache+0xa/0xd >[ 0.188000] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.188000] ? acpi_terminate+0x5/0xf >[ 0.188000] ? acpi_init+0x288/0x32e >[ 0.188000] ? __class_create+0x4c/0x80 >[ 0.188000] ? video_setup+0x7a/0x7a >[ 0.188000] ? do_one_initcall+0x4e/0x1b0 >[ 0.188000] ? kernel_init_freeable+0x194/0x21a >[ 0.188000] ? rest_init+0x80/0x80 >[ 0.188000] ? kernel_init+0xa/0x100 >[ 0.188000] ? ret_from_fork+0x25/0x30 When early abort is occurred due to invalid ACPI information, Linux kernel terminates ACPI by calling acpi_terminate() function. The function calls acpi_ns_terminate() function to delete namespace data and ACPI operand cache (acpi_gbl_module_code_list). But the deletion code in acpi_ns_terminate() function is wrapped in ACPI_EXEC_APP definition, therefore the code is only executed when the definition exists. If the define doesn't exist, ACPI operand cache (acpi_gbl_module_code_list) is leaked, and stack dump is shown in kernel log. This causes a security threat because the old kernel (<= 4.9) shows memory locations of kernel functions in stack dump, therefore kernel ASLR can be neutralized. To fix ACPI operand leak for enhancing security, I made a patch which removes the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the deletion code unconditionally. Link: https://github.com/acpica/acpica/commit/a23325b2 Signed-off-by: Seunghun Han <kkamagui(a)gmail.com> Signed-off-by: Lv Zheng <lv.zheng(a)intel.com> Signed-off-by: Bob Moore <robert.moore(a)intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Acked-by: Lee, Chun-Yi <jlee(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/acpica/nsutils.c | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-) --- a/drivers/acpi/acpica/nsutils.c +++ b/drivers/acpi/acpica/nsutils.c @@ -593,25 +593,20 @@ struct acpi_namespace_node *acpi_ns_vali void acpi_ns_terminate(void) { acpi_status status; + union acpi_operand_object *prev; + union acpi_operand_object *next; ACPI_FUNCTION_TRACE(ns_terminate); -#ifdef ACPI_EXEC_APP - { - union acpi_operand_object *prev; - union acpi_operand_object *next; + /* Delete any module-level code blocks */ - /* Delete any module-level code blocks */ - - next = acpi_gbl_module_code_list; - while (next) { - prev = next; - next = next->method.mutex; - prev->method.mutex = NULL; /* Clear the Mutex (cheated) field */ - acpi_ut_remove_reference(prev); - } + next = acpi_gbl_module_code_list; + while (next) { + prev = next; + next = next->method.mutex; + prev->method.mutex = NULL; /* Clear the Mutex (cheated) field */ + acpi_ut_remove_reference(prev); } -#endif /* * Free the entire namespace -- all nodes and all objects Patches currently in stable-queue which might be from kkamagui(a)gmail.com are queue-4.4/acpica-namespace-fix-operand-cache-leak.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] Patch "ACPI / scan: Prefer devices without _HID/_CID for _ADR matching" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI / scan: Prefer devices without _HID/_CID for _ADR matching to the 4.4-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: acpi-scan-prefer-devices-without-_hid-_cid-for-_adr-matching.patch and it can be found in the queue-4.4 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. >From c2a6bbaf0c5f90463a7011a295bbdb7e33c80b51 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> Date: Fri, 30 Dec 2016 02:27:31 +0100 Subject: ACPI / scan: Prefer devices without _HID/_CID for _ADR matching From: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> commit c2a6bbaf0c5f90463a7011a295bbdb7e33c80b51 upstream. The way acpi_find_child_device() works currently is that, if there are two (or more) devices with the same _ADR value in the same namespace scope (which is not specifically allowed by the spec and the OS behavior in that case is not defined), the first one of them found to be present (with the help of _STA) will be returned. This covers the majority of cases, but is not sufficient if some of the devices in question have a _HID (or _CID) returning some valid ACPI/PNP device IDs (which is disallowed by the spec) and the ASL writers' expectation appears to be that the OS will match devices without a valid ACPI/PNP device ID against a given bus address first. To cover this special case as well, modify find_child_checks() to prefer devices without ACPI/PNP device IDs over devices that have them. Suggested-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Tested-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/glue.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/drivers/acpi/glue.c +++ b/drivers/acpi/glue.c @@ -99,13 +99,13 @@ static int find_child_checks(struct acpi return -ENODEV; /* - * If the device has a _HID (or _CID) returning a valid ACPI/PNP - * device ID, it is better to make it look less attractive here, so that - * the other device with the same _ADR value (that may not have a valid - * device ID) can be matched going forward. [This means a second spec - * violation in a row, so whatever we do here is best effort anyway.] + * If the device has a _HID returning a valid ACPI/PNP device ID, it is + * better to make it look less attractive here, so that the other device + * with the same _ADR value (that may not have a valid device ID) can be + * matched going forward. [This means a second spec violation in a row, + * so whatever we do here is best effort anyway.] */ - return sta_present && list_empty(&adev->pnp.ids) ? + return sta_present && !adev->pnp.type.platform_id ? FIND_CHILD_MAX_SCORE : FIND_CHILD_MIN_SCORE; } Patches currently in stable-queue which might be from rafael.j.wysocki(a)intel.com are queue-4.4/pm-sleep-declare-__tracedata-symbols-as-char-rather-than-char.patch queue-4.4/acpi-processor-avoid-reserving-io-regions-too-early.patch queue-4.4/x86-cpu-intel-introduce-macros-for-intel-family-numbers.patch queue-4.4/acpica-namespace-fix-operand-cache-leak.patch queue-4.4/acpi-scan-prefer-devices-without-_hid-_cid-for-_adr-matching.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] Patch "ACPI / processor: Avoid reserving IO regions too early" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI / processor: Avoid reserving IO regions too early to the 4.4-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: acpi-processor-avoid-reserving-io-regions-too-early.patch and it can be found in the queue-4.4 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. >From 86314751c7945fa0c67f459beeda2e7c610ca429 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> Date: Thu, 2 Jun 2016 01:57:50 +0200 Subject: ACPI / processor: Avoid reserving IO regions too early From: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> commit 86314751c7945fa0c67f459beeda2e7c610ca429 upstream. Roland Dreier reports that one of his systems cannot boot because of the changes made by commit ac212b6980d8 (ACPI / processor: Use common hotplug infrastructure). The problematic part of it is the request_region() call in acpi_processor_get_info() that used to run at module init time before the above commit and now it runs much earlier. Unfortunately, the region(s) reserved by it fall into a range the PCI subsystem attempts to reserve for AHCI IO BARs. As a result, the PCI reservation fails and AHCI doesn't work, while previously the PCI reservation would be made before acpi_processor_get_info() and it would succeed. That request_region() call, however, was overlooked by commit ac212b6980d8, as it is not necessary for the enumeration of the processors. It only is needed when the ACPI processor driver actually attempts to handle them which doesn't happen before loading the ACPI processor driver module. Therefore that call should have been moved from acpi_processor_get_info() into that module. Address the problem by moving the request_region() call in question out of acpi_processor_get_info() and use the observation that the region reserved by it is only needed if the FADT-based CPU throttling method is going to be used, which means that it should be sufficient to invoke it from acpi_processor_get_throttling_fadt(). Fixes: ac212b6980d8 (ACPI / processor: Use common hotplug infrastructure) Reported-by: Roland Dreier <roland(a)purestorage.com> Tested-by: Roland Dreier <roland(a)purestorage.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Acked-by: Joerg Roedel <jroedel(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/acpi_processor.c | 9 --------- drivers/acpi/processor_throttling.c | 9 +++++++++ 2 files changed, 9 insertions(+), 9 deletions(-) --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -331,15 +331,6 @@ static int acpi_processor_get_info(struc pr->throttling.duty_width = acpi_gbl_FADT.duty_width; pr->pblk = object.processor.pblk_address; - - /* - * We don't care about error returns - we just try to mark - * these reserved so that nobody else is confused into thinking - * that this region might be unused.. - * - * (In particular, allocating the IO range for Cardbus) - */ - request_region(pr->throttling.address, 6, "ACPI CPU throttle"); } /* --- a/drivers/acpi/processor_throttling.c +++ b/drivers/acpi/processor_throttling.c @@ -676,6 +676,15 @@ static int acpi_processor_get_throttling if (!pr->flags.throttling) return -ENODEV; + /* + * We don't care about error returns - we just try to mark + * these reserved so that nobody else is confused into thinking + * that this region might be unused.. + * + * (In particular, allocating the IO range for Cardbus) + */ + request_region(pr->throttling.address, 6, "ACPI CPU throttle"); + pr->throttling.state = 0; duty_mask = pr->throttling.state_count - 1; Patches currently in stable-queue which might be from rafael.j.wysocki(a)intel.com are queue-4.4/pm-sleep-declare-__tracedata-symbols-as-char-rather-than-char.patch queue-4.4/acpi-processor-avoid-reserving-io-regions-too-early.patch queue-4.4/x86-cpu-intel-introduce-macros-for-intel-family-numbers.patch queue-4.4/acpica-namespace-fix-operand-cache-leak.patch queue-4.4/acpi-scan-prefer-devices-without-_hid-_cid-for-_adr-matching.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] Patch "netfilter: xt_osf: Add missing permission checks" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: xt_osf: Add missing permission checks 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: netfilter-xt_osf-add-missing-permission-checks.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. >From 916a27901de01446bcf57ecca4783f6cff493309 Mon Sep 17 00:00:00 2001 From: Kevin Cernekee <cernekee(a)chromium.org> Date: Tue, 5 Dec 2017 15:42:41 -0800 Subject: netfilter: xt_osf: Add missing permission checks From: Kevin Cernekee <cernekee(a)chromium.org> commit 916a27901de01446bcf57ecca4783f6cff493309 upstream. The capability check in nfnetlink_rcv() verifies that the caller has CAP_NET_ADMIN in the namespace that "owns" the netlink socket. However, xt_osf_fingers is shared by all net namespaces on the system. An unprivileged user can create user and net namespaces in which he holds CAP_NET_ADMIN to bypass the netlink_net_capable() check: vpnns -- nfnl_osf -f /tmp/pf.os vpnns -- nfnl_osf -f /tmp/pf.os -d These non-root operations successfully modify the systemwide OS fingerprint list. Add new capable() checks so that they can't. Signed-off-by: Kevin Cernekee <cernekee(a)chromium.org> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Acked-by: Michal Kubecek <mkubecek(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/xt_osf.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/net/netfilter/xt_osf.c +++ b/net/netfilter/xt_osf.c @@ -19,6 +19,7 @@ #include <linux/module.h> #include <linux/kernel.h> +#include <linux/capability.h> #include <linux/if.h> #include <linux/inetdevice.h> #include <linux/ip.h> @@ -70,6 +71,9 @@ static int xt_osf_add_callback(struct ne struct xt_osf_finger *kf = NULL, *sf; int err = 0; + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + if (!osf_attrs[OSF_ATTR_FINGER]) return -EINVAL; @@ -115,6 +119,9 @@ static int xt_osf_remove_callback(struct struct xt_osf_finger *sf; int err = -ENOENT; + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + if (!osf_attrs[OSF_ATTR_FINGER]) return -EINVAL; Patches currently in stable-queue which might be from cernekee(a)chromium.org are queue-4.14/netfilter-xt_osf-add-missing-permission-checks.patch queue-4.14/netfilter-nfnetlink_cthelper-add-missing-permission-checks.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] Patch "netfilter: nfnetlink_cthelper: Add missing permission checks" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: nfnetlink_cthelper: Add missing permission checks 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: netfilter-nfnetlink_cthelper-add-missing-permission-checks.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. >From 4b380c42f7d00a395feede754f0bc2292eebe6e5 Mon Sep 17 00:00:00 2001 From: Kevin Cernekee <cernekee(a)chromium.org> Date: Sun, 3 Dec 2017 12:12:45 -0800 Subject: netfilter: nfnetlink_cthelper: Add missing permission checks From: Kevin Cernekee <cernekee(a)chromium.org> commit 4b380c42f7d00a395feede754f0bc2292eebe6e5 upstream. The capability check in nfnetlink_rcv() verifies that the caller has CAP_NET_ADMIN in the namespace that "owns" the netlink socket. However, nfnl_cthelper_list is shared by all net namespaces on the system. An unprivileged user can create user and net namespaces in which he holds CAP_NET_ADMIN to bypass the netlink_net_capable() check: $ nfct helper list nfct v1.4.4: netlink error: Operation not permitted $ vpnns -- nfct helper list { .name = ftp, .queuenum = 0, .l3protonum = 2, .l4protonum = 6, .priv_data_len = 24, .status = enabled, }; Add capable() checks in nfnetlink_cthelper, as this is cleaner than trying to generalize the solution. Signed-off-by: Kevin Cernekee <cernekee(a)chromium.org> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Acked-by: Michal Kubecek <mkubecek(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/nfnetlink_cthelper.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/net/netfilter/nfnetlink_cthelper.c +++ b/net/netfilter/nfnetlink_cthelper.c @@ -17,6 +17,7 @@ #include <linux/types.h> #include <linux/list.h> #include <linux/errno.h> +#include <linux/capability.h> #include <net/netlink.h> #include <net/sock.h> @@ -407,6 +408,9 @@ static int nfnl_cthelper_new(struct net struct nfnl_cthelper *nlcth; int ret = 0; + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + if (!tb[NFCTH_NAME] || !tb[NFCTH_TUPLE]) return -EINVAL; @@ -611,6 +615,9 @@ static int nfnl_cthelper_get(struct net struct nfnl_cthelper *nlcth; bool tuple_set = false; + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + if (nlh->nlmsg_flags & NLM_F_DUMP) { struct netlink_dump_control c = { .dump = nfnl_cthelper_dump_table, @@ -678,6 +685,9 @@ static int nfnl_cthelper_del(struct net struct nfnl_cthelper *nlcth, *n; int j = 0, ret; + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + if (tb[NFCTH_NAME]) helper_name = nla_data(tb[NFCTH_NAME]); Patches currently in stable-queue which might be from cernekee(a)chromium.org are queue-4.14/netfilter-xt_osf-add-missing-permission-checks.patch queue-4.14/netfilter-nfnetlink_cthelper-add-missing-permission-checks.patch

7 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror