July 2018 - Linux-stable-mirror

Are you sure?

by Ms CHIANG Lai Yuen JP

I have a Businesss Proposal for you, Can you do it? If yes please get back to me for more details.

5 years, 9 months

1
0
0 0

[PATCH for-4.4.y 0/5] net/sched: init failure fixes

by Amit Pundir

Hi Greg, Kindly consider/review following net/sched fixes for stable 4.4.y. This patchset is a follow-up of upstream fix 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation") cherry-picked on stable 4.4.y. It fix null pointer dereferences due to uninitialized timer (qdisc watchdog) or double frees due to ->destroy cleaning up a second time. Here is the original submission https://www.mail-archive.com/netdev@vger.kernel.org/msg186003.html Cherry-picked and build tested on Linux 4.4.145 for ARCH=arm/arm64. Regards, Amit Pundir Nikolay Aleksandrov (5): sch_htb: fix crash on init failure sch_multiq: fix double free on init failure sch_hhf: fix null pointer dereference on init failure sch_netem: avoid null pointer deref on init failure sch_tbf: fix two null pointer dereferences on init failure net/sched/sch_hhf.c | 3 +++ net/sched/sch_htb.c | 5 +++-- net/sched/sch_multiq.c | 7 +------ net/sched/sch_netem.c | 4 ++-- net/sched/sch_tbf.c | 5 +++-- 5 files changed, 12 insertions(+), 12 deletions(-) -- 2.7.4

5 years, 9 months

1
5
0 0

[PATCH] x86/microcode: Don't duplicate code to update ucode cpu info and cpu info

by Filippo Sironi

... on late microcode loading when handling a CPU that's already been updated and a CPU that's yet to be updated. Signed-off-by: Filippo Sironi <sironi(a)amazon.de> --- arch/x86/kernel/cpu/microcode/amd.c | 15 +++++++++------ arch/x86/kernel/cpu/microcode/intel.c | 10 ++++++---- 2 files changed, 15 insertions(+), 10 deletions(-) diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c index 0624957aa068..77758e10f16f 100644 --- a/arch/x86/kernel/cpu/microcode/amd.c +++ b/arch/x86/kernel/cpu/microcode/amd.c @@ -505,6 +505,7 @@ static enum ucode_state apply_microcode_amd(int cpu) struct ucode_cpu_info *uci; struct ucode_patch *p; u32 rev, dummy; + enum ucode_state ret; BUG_ON(raw_smp_processor_id() != cpu); @@ -521,9 +522,8 @@ static enum ucode_state apply_microcode_amd(int cpu) /* need to apply patch? */ if (rev >= mc_amd->hdr.patch_id) { - c->microcode = rev; - uci->cpu_sig.rev = rev; - return UCODE_OK; + ret = UCODE_OK; + goto out; } if (__apply_microcode_amd(mc_amd)) { @@ -534,10 +534,13 @@ static enum ucode_state apply_microcode_amd(int cpu) pr_info("CPU%d: new patch_level=0x%08x\n", cpu, mc_amd->hdr.patch_id); - uci->cpu_sig.rev = mc_amd->hdr.patch_id; - c->microcode = mc_amd->hdr.patch_id; + ret = UCODE_UPDATED; + rev = mc_amd->hdr.patch_id; +out: + uci->cpu_sig.rev = rev; + c->microcode = rev; - return UCODE_UPDATED; + return ret; } static int install_equiv_cpu_table(const u8 *buf) diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c index 97ccf4c3b45b..4bc869e829eb 100644 --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -797,6 +797,7 @@ static enum ucode_state apply_microcode_intel(int cpu) struct microcode_intel *mc; static int prev_rev; u32 rev; + enum ucode_state ret; /* We should bind the task to the CPU */ if (WARN_ON(raw_smp_processor_id() != cpu)) @@ -817,9 +818,8 @@ static enum ucode_state apply_microcode_intel(int cpu) */ rev = intel_get_microcode_revision(); if (rev >= mc->hdr.rev) { - uci->cpu_sig.rev = rev; - c->microcode = rev; - return UCODE_OK; + ret = UCODE_OK; + goto out; } /* @@ -848,10 +848,12 @@ static enum ucode_state apply_microcode_intel(int cpu) prev_rev = rev; } + ret = UCODE_UPDATED; +out: uci->cpu_sig.rev = rev; c->microcode = rev; - return UCODE_UPDATED; + return ret; } static enum ucode_state generic_load_microcode(int cpu, void *data, size_t size, -- 2.7.4

5 years, 9 months

3
3
0 0

[PATCH 1/3] ext4: super: Fix spectre gadget in ext4_quota_on

by Jeremy Cline

'type' is a user-controlled value used to index into 's_qf_names', which can be used in a Spectre v1 attack. Clamp 'type' to the size of the array to avoid a speculative out-of-bounds read. Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Jeremy Cline <jcline(a)redhat.com> --- fs/ext4/super.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 6480e763080f..c04a09b51742 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -40,6 +40,7 @@ #include <linux/crc16.h> #include <linux/dax.h> #include <linux/cleancache.h> +#include <linux/nospec.h> #include <linux/uaccess.h> #include <linux/iversion.h> @@ -5559,6 +5560,7 @@ static int ext4_quota_on(struct super_block *sb, int type, int format_id, if (path->dentry->d_sb != sb) return -EXDEV; /* Journaling quota? */ + type = array_index_nospec(type, EXT4_MAXQUOTAS); if (EXT4_SB(sb)->s_qf_names[type]) { /* Quotafile not in fs root? */ if (path->dentry->d_parent != sb->s_root) -- 2.17.1

5 years, 9 months

3
4
0 0

[PATCH] kernel.h: Disable -Wreturn-stack-address for _THIS_IP_

by Nick Desaulniers

Starting with Clang-7.0, _THIS_IP_ generates -Wreturn-stack-address warnings for almost every translation unit. In general, I'd prefer to leave this on (returning the address of a stack allocated variable is in general a bad idea) and disable it only at whitelisted call sites. We can't do something like: #pragma clang diagnostic push #pragma clang diagnostic ignored "-Wreturn-stack-address" <code> #pragma clang diagnostic pop in a GNU Statement Expression or macro, hence we use _Pragma, which is its raison d'être: https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html Cc: stable(a)vger.kernel.org # 4.17, 4.14, 4.9, 4.4 Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com> --- include/linux/kernel.h | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/include/linux/kernel.h b/include/linux/kernel.h index 941dc0a5a877..5906f5727f90 100644 --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -168,7 +168,15 @@ #define _RET_IP_ (unsigned long)__builtin_return_address(0) -#define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; }) +#define _THIS_IP_ ( \ +{ \ + _Pragma("clang diagnostic push") \ + _Pragma("clang diagnostic ignored \"-Wreturn-stack-address\"") \ + __label__ __here; \ +__here: (unsigned long)&&__here; \ + _Pragma("clang diagnostic pop") \ +} \ +) #ifdef CONFIG_LBDAF # include <asm/div64.h> -- 2.18.0.233.g985f88cf7e-goog

5 years, 9 months

3
6
0 0

[PATCH v2] arch/x86: Fix boot_cpu_data.microcode version output

by Prarit Bhargava

I tested this on AMD Ryzen & Intel Broadwell system and dumped the boot_cpu_data before and after a microcode update. On the Intel system I also did a fatal MCE using mce-inject to confirm the output from the mce handling code. P. ---8<--- On systems where a runtime microcode update has occurred the microcode version output in a MCE log record is wrong because boot_cpu_data.microcode is not updated during runtime. Update boot_cpu_data.microcode when the BSP's microcode is updated. Fixes: fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check records") Suggested-by: Borislav Petkov <bp(a)alien8.com> Signed-off-by: Prarit Bhargava <prarit(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: sironi(a)amazon.de Cc: tony.luck(a)intel.com --- Changes in v2: Use mc_amd->hdr.patch_id on AMD arch/x86/kernel/cpu/microcode/amd.c | 4 ++++ arch/x86/kernel/cpu/microcode/intel.c | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c index 0624957aa068..63b072377ba4 100644 --- a/arch/x86/kernel/cpu/microcode/amd.c +++ b/arch/x86/kernel/cpu/microcode/amd.c @@ -537,6 +537,10 @@ static enum ucode_state apply_microcode_amd(int cpu) uci->cpu_sig.rev = mc_amd->hdr.patch_id; c->microcode = mc_amd->hdr.patch_id; + /* Update boot_cpu_data's revision too, if we're on the BSP: */ + if (c->cpu_index == boot_cpu_data.cpu_index) + boot_cpu_data.microcode = mc_amd->hdr.patch_id; + return UCODE_UPDATED; } diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c index 97ccf4c3b45b..256d336cbc04 100644 --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -851,6 +851,10 @@ static enum ucode_state apply_microcode_intel(int cpu) uci->cpu_sig.rev = rev; c->microcode = rev; + /* Update boot_cpu_data's revision too, if we're on the BSP: */ + if (c->cpu_index == boot_cpu_data.cpu_index) + boot_cpu_data.microcode = rev; + return UCODE_UPDATED; } -- 2.17.0

5 years, 9 months

3
3
0 0

[PATCH v2] ipc/shm.c add ->pagesize function to shm_vm_ops

by Jane Chu

05ea88608d4e13 ("mm, hugetlbfs: introduce ->pagesize() to vm_operations_struct") adds a new ->pagesize() function to hugetlb_vm_ops, intended to cover all hugetlbfs backed files. With System V shared memory model, if "huge page" is specified, the "shared memory" is backed by hugetlbfs files, but the mappings initiated via shmget/shmat have their original vm_ops overwritten with shm_vm_ops, so we need to add a ->pagesize function to shm_vm_ops. Otherwise, vma_kernel_pagesize() returns PAGE_SIZE given a hugetlbfs backed vma, result in below BUG: fs/hugetlbfs/inode.c 443 if (unlikely(page_mapped(page))) { 444 BUG_ON(truncate_op); [ 242.268342] hugetlbfs: oracle (4592): Using mlock ulimits for SHM_HUGETLB is deprecated [ 282.653208] ------------[ cut here ]------------ [ 282.708447] kernel BUG at fs/hugetlbfs/inode.c:444! [ 282.818957] Modules linked in: nfsv3 rpcsec_gss_krb5 nfsv4 ... [ 284.025873] CPU: 35 PID: 5583 Comm: oracle_5583_sbt Not tainted 4.14.35-1829.el7uek.x86_64 #2 [ 284.246609] task: ffff9bf0507aaf80 task.stack: ffffa9e625628000 [ 284.317455] RIP: 0010:remove_inode_hugepages+0x3db/0x3e2 .... [ 285.292389] Call Trace: [ 285.321630] hugetlbfs_evict_inode+0x1e/0x3e [ 285.372707] evict+0xdb/0x1af [ 285.408185] iput+0x1a2/0x1f7 [ 285.443661] dentry_unlink_inode+0xc6/0xf0 [ 285.492661] __dentry_kill+0xd8/0x18d [ 285.536459] dput+0x1b5/0x1ed [ 285.571939] __fput+0x18b/0x216 [ 285.609495] ____fput+0xe/0x10 [ 285.646030] task_work_run+0x90/0xa7 [ 285.688788] exit_to_usermode_loop+0xdd/0x116 [ 285.740905] do_syscall_64+0x187/0x1ae [ 285.785740] entry_SYSCALL_64_after_hwframe+0x150/0x0 Link: http://lkml.kernel.org/r/20180727211727.5020-1-jane.chu@oracle.com Fixes: 05ea88608d4e13 ("mm, hugetlbfs: introduce ->pagesize() to vm_operations_struct") Signed-off-by: Jane Chu <jane.chu(a)oracle.com> Suggested-by: Mike Kravetz <mike.kravetz(a)oracle.com> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Acked-by: Davidlohr Bueso <dbueso(a)suse.de> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Jan Kara <jack(a)suse.cz> Cc: JÃ©rÃ´me Glisse <jglisse(a)redhat.com> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Manfred Spraul <manfred(a)colorfullife.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- --- ipc/shm.c | 12 ++++++++++++ mm/hugetlb.c | 7 +++++++ 2 files changed, 19 insertions(+) diff --git a/ipc/shm.c b/ipc/shm.c index 051a3e1fb8df..fefa00d310fb 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -427,6 +427,17 @@ static int shm_split(struct vm_area_struct *vma, unsigned long addr) return 0; } +static unsigned long shm_pagesize(struct vm_area_struct *vma) +{ + struct file *file = vma->vm_file; + struct shm_file_data *sfd = shm_file_data(file); + + if (sfd->vm_ops->pagesize) + return sfd->vm_ops->pagesize(vma); + + return PAGE_SIZE; +} + #ifdef CONFIG_NUMA static int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new) { @@ -554,6 +565,7 @@ static const struct vm_operations_struct shm_vm_ops = { .close = shm_close, /* callback for when the vm-area is released */ .fault = shm_fault, .split = shm_split, + .pagesize = shm_pagesize, #if defined(CONFIG_NUMA) .set_policy = shm_set_policy, .get_policy = shm_get_policy, diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 039ddbc574e9..3103099f64fd 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3167,6 +3167,13 @@ static vm_fault_t hugetlb_vm_op_fault(struct vm_fault *vmf) return 0; } +/* + * When a new function is introduced to vm_operations_struct and added + * to hugetlb_vm_ops, please consider adding the function to shm_vm_ops. + * This is because under System V memory model, mappings created via + * shmget/shmat with "huge page" specified are backed by hugetlbfs files, + * their original vm_ops are overwritten with shm_vm_ops. + */ const struct vm_operations_struct hugetlb_vm_ops = { .fault = hugetlb_vm_op_fault, .open = hugetlb_vm_op_open, -- 2.15.GIT

5 years, 9 months

1
0
0 0

[PATCH] arch/x86: Fix boot_cpu_data.microcode version output

by Prarit Bhargava

On systems where a runtime microcode update has occurred the microcode version output in a MCE log record is wrong because boot_cpu_data.microcode is not updated during runtime. Update boot_cpu_data.microcode when the BSP's microcode is updated. Fixes: fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check records") Suggested-by: Borislav Petkov <bp(a)alien8.com> Signed-off-by: Prarit Bhargava <prarit(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: sironi(a)amazon.de Cc: tony.luck(a)intel.com --- arch/x86/kernel/cpu/microcode/amd.c | 4 ++++ arch/x86/kernel/cpu/microcode/intel.c | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c index 0624957aa068..7f5b32535ac7 100644 --- a/arch/x86/kernel/cpu/microcode/amd.c +++ b/arch/x86/kernel/cpu/microcode/amd.c @@ -537,6 +537,10 @@ static enum ucode_state apply_microcode_amd(int cpu) uci->cpu_sig.rev = mc_amd->hdr.patch_id; c->microcode = mc_amd->hdr.patch_id; + /* Update boot_cpu_data's revision too, if we're on the BSP: */ + if (c->cpu_index == boot_cpu_data.cpu_index) + boot_cpu_data.microcode = rev; + return UCODE_UPDATED; } diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c index 97ccf4c3b45b..256d336cbc04 100644 --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -851,6 +851,10 @@ static enum ucode_state apply_microcode_intel(int cpu) uci->cpu_sig.rev = rev; c->microcode = rev; + /* Update boot_cpu_data's revision too, if we're on the BSP: */ + if (c->cpu_index == boot_cpu_data.cpu_index) + boot_cpu_data.microcode = rev; + return UCODE_UPDATED; } -- 2.17.0

5 years, 9 months

2
2
0 0

[PATCH] qedi: Fix a potential buffer overflow

by Bart Van Assche

Tell snprintf() to store at most 255 characters in the output buffer instead of 256. This patch avoids that smatch reports the following warning: drivers/scsi/qedi/qedi_main.c:891: qedi_get_boot_tgt_info() error: snprintf() is printing too much 256 vs 255 Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: <QLogic-Storage-Upstream(a)cavium.com> Cc: <stable(a)vger.kernel.org> --- drivers/scsi/qedi/qedi_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/qedi_main.c index 682f3ce31014..ea62180d9ec8 100644 --- a/drivers/scsi/qedi/qedi_main.c +++ b/drivers/scsi/qedi/qedi_main.c @@ -888,7 +888,7 @@ static void qedi_get_boot_tgt_info(struct nvm_iscsi_block *block, ipv6_en = !!(block->generic.ctrl_flags & NVM_ISCSI_CFG_GEN_IPV6_ENABLED); - snprintf(tgt->iscsi_name, NVM_ISCSI_CFG_ISCSI_NAME_MAX_LEN, "%s\n", + snprintf(tgt->iscsi_name, sizeof(tgt->iscsi_name), "%s\n", block->target[index].target_name.byte); tgt->ipv6_en = ipv6_en; -- 2.18.0

5 years, 9 months

3
2
0 0

Richard & Angela Maxwell Congratulates You..

by Richard & Angela Maxwell

My wife and I won the Euro Millions Lottery of 53 Million British Pounds and we have voluntarily decided to donate 1,000,000GBP(One Million British Pounds) to 5 individuals randomly as part of our own charity project. To verify our lottery winnings,please see our interview by visiting the web page below: http://www.telegraph.co.uk/news/newstopics/howaboutthat/11511467/Lincolnshi… Lincolnshire couple thought £53m EuroMillions win was ... A retired couple who have become one of the country's biggest ever National Lottery winners after bagging more than £53 million at first thought it was an April Fool's joke. Richard and Angela Maxwell, from Boston in Lincolnshire, scooped £53,193,914 after winning the EuroMillions jackpot draw on ... www.telegraph.co.uk After a computer spinball,your email address was among the emails which were submitted to us by the Google, Inc as a web user; ifyou have received our email, kindly send us the below details so that we can transfer your 1,000,000.00 GBP(One Million Pounds) in your name or direct our paying bank to effect the transfer of the funds to your designated bank account in your own country. Full Names: Mobile No: Age: Address: Send your response to: richangela203(a)hotmail.com or richangela22<3057927356(a)qq.com> Best Regards, Richard & Angela Maxwell

5 years, 9 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2018