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

Patch "rxrpc: check return value of skb_to_sgvec always" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rxrpc: check return value of skb_to_sgvec always to the 4.9-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: rxrpc-check-return-value-of-skb_to_sgvec-always.patch and it can be found in the queue-4.9 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 89a5ea99662505d2d61f2a3030a6896c2cb3cdb0 Mon Sep 17 00:00:00 2001 From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> Date: Sun, 4 Jun 2017 04:16:24 +0200 Subject: rxrpc: check return value of skb_to_sgvec always From: Jason A. Donenfeld <Jason(a)zx2c4.com> commit 89a5ea99662505d2d61f2a3030a6896c2cb3cdb0 upstream. Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> Acked-by: David Howells <dhowells(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rxrpc/rxkad.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) --- a/net/rxrpc/rxkad.c +++ b/net/rxrpc/rxkad.c @@ -229,7 +229,9 @@ static int rxkad_secure_packet_encrypt(c len &= ~(call->conn->size_align - 1); sg_init_table(sg, nsg); - skb_to_sgvec(skb, sg, 0, len); + err = skb_to_sgvec(skb, sg, 0, len); + if (unlikely(err < 0)) + goto out; skcipher_request_set_crypt(req, sg, sg, len, iv.x); crypto_skcipher_encrypt(req); @@ -325,7 +327,7 @@ static int rxkad_verify_packet_1(struct struct sk_buff *trailer; u32 data_size, buf; u16 check; - int nsg; + int nsg, ret; _enter(""); @@ -342,7 +344,9 @@ static int rxkad_verify_packet_1(struct goto nomem; sg_init_table(sg, nsg); - skb_to_sgvec(skb, sg, offset, 8); + ret = skb_to_sgvec(skb, sg, offset, 8); + if (unlikely(ret < 0)) + return ret; /* start the decryption afresh */ memset(&iv, 0, sizeof(iv)); @@ -405,7 +409,7 @@ static int rxkad_verify_packet_2(struct struct sk_buff *trailer; u32 data_size, buf; u16 check; - int nsg; + int nsg, ret; _enter(",{%d}", skb->len); @@ -429,7 +433,12 @@ static int rxkad_verify_packet_2(struct } sg_init_table(sg, nsg); - skb_to_sgvec(skb, sg, offset, len); + ret = skb_to_sgvec(skb, sg, offset, len); + if (unlikely(ret < 0)) { + if (sg != _sg) + kfree(sg); + return ret; + } /* decrypt from the session key */ token = call->conn->params.key->payload.data[0]; Patches currently in stable-queue which might be from Jason(a)zx2c4.com are queue-4.9/ipsec-check-return-value-of-skb_to_sgvec-always.patch queue-4.9/skbuff-return-emsgsize-in-skb_to_sgvec-to-prevent-overflow.patch queue-4.9/rxrpc-check-return-value-of-skb_to_sgvec-always.patch queue-4.9/virtio_net-check-return-value-of-skb_to_sgvec-always.patch queue-4.9/macsec-check-return-value-of-skb_to_sgvec-always.patch queue-4.9/virtio_net-check-return-value-of-skb_to_sgvec-in-one-more-location.patch

7 years, 7 months

1
0
0 0

[PATCH] f2fs: don't use GFP_ZERO for page caches

by Jaegeuk Kim

From: Chao Yu <yuchao0(a)huawei.com> Related to https://lkml.org/lkml/2018/4/8/661 Sometimes, we need to write meta data to new allocated block address, then we will allocate a zeroed page in inner inode's address space, and fill partial data in it, and leave other place with zero value which means some fields are initial status. There are two inner inodes (meta inode and node inode) setting __GFP_ZERO, I have just checked them, for both of them, we can avoid using __GFP_ZERO, and do initialization by ourselves to avoid unneeded/redundant zeroing from mm. Cc: <stable(a)vger.kernel.org> Signed-off-by: Chao Yu <yuchao0(a)huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> --- fs/f2fs/inode.c | 4 ++-- fs/f2fs/node.c | 6 ++++-- fs/f2fs/node.h | 7 ++----- fs/f2fs/recovery.c | 3 +-- 4 files changed, 9 insertions(+), 11 deletions(-) diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c index 417c9dcd0269..87535bf63421 100644 --- a/fs/f2fs/inode.c +++ b/fs/f2fs/inode.c @@ -320,10 +320,10 @@ struct inode *f2fs_iget(struct super_block *sb, unsigned long ino) make_now: if (ino == F2FS_NODE_INO(sbi)) { inode->i_mapping->a_ops = &f2fs_node_aops; - mapping_set_gfp_mask(inode->i_mapping, GFP_F2FS_ZERO); + mapping_set_gfp_mask(inode->i_mapping, GFP_NOFS); } else if (ino == F2FS_META_INO(sbi)) { inode->i_mapping->a_ops = &f2fs_meta_aops; - mapping_set_gfp_mask(inode->i_mapping, GFP_F2FS_ZERO); + mapping_set_gfp_mask(inode->i_mapping, GFP_NOFS); } else if (S_ISREG(inode->i_mode)) { inode->i_op = &f2fs_file_inode_operations; inode->i_fop = &f2fs_file_operations; diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index 9a99243054ba..6fc3311820ec 100644 --- a/fs/f2fs/node.c +++ b/fs/f2fs/node.c @@ -1096,7 +1096,8 @@ struct page *new_node_page(struct dnode_of_data *dn, unsigned int ofs) set_node_addr(sbi, &new_ni, NEW_ADDR, false); f2fs_wait_on_page_writeback(page, NODE, true); - fill_node_footer(page, dn->nid, dn->inode->i_ino, ofs, true); + memset(F2FS_NODE(page), 0, PAGE_SIZE); + fill_node_footer(page, dn->nid, dn->inode->i_ino, ofs); set_cold_node(page, S_ISDIR(dn->inode->i_mode)); if (!PageUptodate(page)) SetPageUptodate(page); @@ -2311,7 +2312,8 @@ int recover_inode_page(struct f2fs_sb_info *sbi, struct page *page) if (!PageUptodate(ipage)) SetPageUptodate(ipage); - fill_node_footer(ipage, ino, ino, 0, true); + memset(F2FS_NODE(page), 0, PAGE_SIZE); + fill_node_footer(ipage, ino, ino, 0); set_cold_node(page, false); src = F2FS_INODE(page); diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h index b95e49e4a928..42cd081114ab 100644 --- a/fs/f2fs/node.h +++ b/fs/f2fs/node.h @@ -263,15 +263,12 @@ static inline block_t next_blkaddr_of_node(struct page *node_page) } static inline void fill_node_footer(struct page *page, nid_t nid, - nid_t ino, unsigned int ofs, bool reset) + nid_t ino, unsigned int ofs) { struct f2fs_node *rn = F2FS_NODE(page); unsigned int old_flag = 0; - if (reset) - memset(rn, 0, sizeof(*rn)); - else - old_flag = le32_to_cpu(rn->footer.flag); + old_flag = le32_to_cpu(rn->footer.flag); rn->footer.nid = cpu_to_le32(nid); rn->footer.ino = cpu_to_le32(ino); diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c index 1b23d3febe4c..de24f3247aa5 100644 --- a/fs/f2fs/recovery.c +++ b/fs/f2fs/recovery.c @@ -540,8 +540,7 @@ static int do_recover_data(struct f2fs_sb_info *sbi, struct inode *inode, } copy_node_footer(dn.node_page, page); - fill_node_footer(dn.node_page, dn.nid, ni.ino, - ofs_of_node(page), false); + fill_node_footer(dn.node_page, dn.nid, ni.ino, ofs_of_node(page)); set_page_dirty(dn.node_page); err: f2fs_put_dnode(&dn); -- 2.15.0.531.g2ccb3012c9-goog

7 years, 7 months

2
4
0 0

[PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

by ianwmorrison＠gmail.com

From: Ian W MORRISON <ianwmorrison(a)gmail.com> As the Geminilake firmware is now merged to linux-firmware.git use MODUE_FIRMWARE to load the firmware. This removes the error message in the dmesg log: i915 0000:00:02.0: Direct firmware load for i915/glk_dmc_ver1_04.bin failed with error -2 i915 0000:00:02.0: Failed to load DMC firmware i915/glk_dmc_ver1_04.bin. Disabling runtime power management. i915 0000:00:02.0: DMC firmware homepage: https://01.org/linuxgraphics/downloads/firmware and now shows that the firmware has correctly loaded: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4) Cc: stable(a)vger.kernel.org Signed-off-by: Ian W MORRISON <ianwmorrison(a)gmail.com> --- drivers/gpu/drm/i915/intel_csr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c index 41e6c75a7f3c..f9550ea46c26 100644 --- a/drivers/gpu/drm/i915/intel_csr.c +++ b/drivers/gpu/drm/i915/intel_csr.c @@ -35,6 +35,7 @@ */ #define I915_CSR_GLK "i915/glk_dmc_ver1_04.bin" +MODULE_FIRMWARE(I915_CSR_GLK); #define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 4) #define I915_CSR_CNL "i915/cnl_dmc_ver1_07.bin" -- 2.11.0

7 years, 7 months

1
0
0 0

Fwd: [tip:x86/urgent] x86/platform/UV: Fix critical UV MMR address error

by Mike Travis

This was sent to stable(a)vger.kernel.org almost 2 weeks ago and I haven't heard anything back yet. Is there any update on the status? (sorry for the bad formatting, this is the only way I can forward the email. I can only resend the original email before the commit email from Thomas.) Thanks. -------- Forwarded Message -------- Subject: [tip:x86/urgent] x86/platform/UV: Fix critical UV MMR address error Date: Wed, 28 Mar 2018 11:25:04 -0700 From: tip-bot for mike.travis(a)hpe.com <tipbot(a)zytor.com> Reply-To: andrew.banman(a)hpe.com, hpa(a)zytor.com, tglx(a)linutronix.de, mingo(a)kernel.org, russ.anderson(a)hpe.com, travis(a)sgi.com, linux-kernel(a)vger.kernel.org, mike.travis(a)hpe.com, dimitri.sivanich(a)hpe.com To: linux-tip-commits(a)vger.kernel.org CC: dimitri.sivanich(a)hpe.com, mike.travis(a)hpe.com, linux-kernel(a)vger.kernel.org, mingo(a)kernel.org, hpa(a)zytor.com, tglx(a)linutronix.de, andrew.banman(a)hpe.com, russ.anderson(a)hpe.com, travis(a)sgi.com Commit-ID: bd47a85acd727e27b7283daff557865ad04c59f6 Gitweb: https://git.kernel.org/tip/bd47a85acd727e27b7283daff557865ad04c59f6 Author: mike.travis(a)hpe.com <mike.travis(a)hpe.com> AuthorDate: Wed, 28 Mar 2018 12:40:11 -0500 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitDate: Wed, 28 Mar 2018 20:19:45 +0200 x86/platform/UV: Fix critical UV MMR address error A critical error was found testing the fixed UV4 HUB in that an MMR address was found to be incorrect. This causes the virtual address space for accessing the MMIOH1 region to be allocated with the incorrect size. Fixes: 673aa20c55a1 ("x86/platform/UV: Update uv_mmrs.h to prepare for UV4A fixes") Signed-off-by: Mike Travis <travis(a)sgi.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Dimitri Sivanich <dimitri.sivanich(a)hpe.com> Cc: Russ Anderson <russ.anderson(a)hpe.com> Cc: Andrew Banman <andrew.banman(a)hpe.com> Link: https://lkml.kernel.org/r/20180328174011.041801248@stormcage.americas.sgi.c… --- arch/x86/include/asm/uv/uv_mmrs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/uv/uv_mmrs.h b/arch/x86/include/asm/uv/uv_mmrs.h index ecb9ddef128f..62c79e26a59a 100644 --- a/arch/x86/include/asm/uv/uv_mmrs.h +++ b/arch/x86/include/asm/uv/uv_mmrs.h @@ -3833,7 +3833,7 @@ union uvh_rh_gam_mmioh_overlay_config0_mmr_u { #define UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR uv_undefined("UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR") #define UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR uv_undefined("UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR") #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1603000UL -#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x483000UL +#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x484000UL #define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR ( \ is_uv1_hub() ? UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR : \ is_uv2_hub() ? UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR : \

7 years, 7 months

2
3
0 0

+ ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: ipc/shm: fix use-after-free of shm file via remap_file_pages() has been added to the -mm tree. Its filename is ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/ipc-shm-fix-use-after-free-of-shm-… and later at http://ozlabs.org/~akpm/mmotm/broken-out/ipc-shm-fix-use-after-free-of-shm-… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Eric Biggers <ebiggers(a)google.com> Subject: ipc/shm: fix use-after-free of shm file via remap_file_pages() syzbot reported a use-after-free of shm_file_data(file)->file->f_op in shm_get_unmapped_area(), called via sys_remap_file_pages(). Unfortunately it couldn't generate a reproducer, but I found a bug which I think caused it. When remap_file_pages() is passed a full System V shared memory segment, the memory is first unmapped, then a new map is created using the ->vm_file. Between these steps, the shm ID can be removed and reused for a new shm segment. But, shm_mmap() only checks whether the ID is currently valid before calling the underlying file's ->mmap(); it doesn't check whether it was reused. Thus it can use the wrong underlying file, one that was already freed. Fix this by making the "outer" shm file (the one that gets put in ->vm_file) hold a reference to the real shm file, and by making __shm_open() require that the file associated with the shm ID matches the one associated with the "outer" file. Commit 1ac0b6dec656 ("ipc/shm: handle removed segments gracefully in shm_mmap()") almost fixed this bug, but it didn't go far enough because it didn't consider the case where the shm ID is reused. The following program usually reproduces this bug: #include <stdlib.h> #include <sys/shm.h> #include <sys/syscall.h> #include <unistd.h> int main() { int is_parent = (fork() != 0); srand(getpid()); for (;;) { int id = shmget(0xF00F, 4096, IPC_CREAT|0700); if (is_parent) { void *addr = shmat(id, NULL, 0); usleep(rand() % 50); while (!syscall(__NR_remap_file_pages, addr, 4096, 0, 0, 0)); } else { usleep(rand() % 50); shmctl(id, IPC_RMID, NULL); } } } It causes the following NULL pointer dereference due to a 'struct file' being used while it's being freed. (I couldn't actually get a KASAN use-after-free splat like in the syzbot report. But I think it's possible with this bug; it would just take a more extraordinary race...) BUG: unable to handle kernel NULL pointer dereference at 0000000000000058 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 9 PID: 258 Comm: syz_ipc Not tainted 4.16.0-05140-gf8cf2f16a7c95 #189 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014 RIP: 0010:d_inode include/linux/dcache.h:519 [inline] RIP: 0010:touch_atime+0x25/0xd0 fs/inode.c:1724 [...] Call Trace: file_accessed include/linux/fs.h:2063 [inline] shmem_mmap+0x25/0x40 mm/shmem.c:2149 call_mmap include/linux/fs.h:1789 [inline] shm_mmap+0x34/0x80 ipc/shm.c:465 call_mmap include/linux/fs.h:1789 [inline] mmap_region+0x309/0x5b0 mm/mmap.c:1712 do_mmap+0x294/0x4a0 mm/mmap.c:1483 do_mmap_pgoff include/linux/mm.h:2235 [inline] SYSC_remap_file_pages mm/mmap.c:2853 [inline] SyS_remap_file_pages+0x232/0x310 mm/mmap.c:2769 do_syscall_64+0x64/0x1a0 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 Link: http://lkml.kernel.org/r/20180409043039.28915-1-ebiggers3@gmail.com Reported-by: syzbot+d11f321e7f1923157eac80aa990b446596f46439(a)syzkaller.appspotmail.com Fixes: c8d78c1823f4 ("mm: replace remap_file_pages() syscall with emulation") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Manfred Spraul <manfred(a)colorfullife.com> Cc: "Eric W . Biederman" <ebiederm(a)xmission.com> Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN ipc/shm.c~ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages ipc/shm.c --- a/ipc/shm.c~ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages +++ a/ipc/shm.c @@ -225,6 +225,12 @@ static int __shm_open(struct vm_area_str if (IS_ERR(shp)) return PTR_ERR(shp); + if (shp->shm_file != sfd->file) { + /* ID was reused */ + shm_unlock(shp); + return -EINVAL; + } + shp->shm_atim = ktime_get_real_seconds(); ipc_update_pid(&shp->shm_lprid, task_tgid(current)); shp->shm_nattch++; @@ -455,8 +461,9 @@ static int shm_mmap(struct file *file, s int ret; /* - * In case of remap_file_pages() emulation, the file can represent - * removed IPC ID: propogate shm_lock() error to caller. + * In case of remap_file_pages() emulation, the file can represent an + * IPC ID that was removed, and possibly even reused by another shm + * segment already. Propagate this case as an error to caller. */ ret = __shm_open(vma); if (ret) @@ -480,6 +487,7 @@ static int shm_release(struct inode *ino struct shm_file_data *sfd = shm_file_data(file); put_ipc_ns(sfd->ns); + fput(sfd->file); shm_file_data(file) = NULL; kfree(sfd); return 0; @@ -1432,7 +1440,7 @@ long do_shmat(int shmid, char __user *sh file->f_mapping = shp->shm_file->f_mapping; sfd->id = shp->shm_perm.id; sfd->ns = get_ipc_ns(ns); - sfd->file = shp->shm_file; + sfd->file = get_file(shp->shm_file); sfd->vm_ops = NULL; err = security_mmap_file(file, prot, flags); _ Patches currently in -mm which might be from ebiggers(a)google.com are ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch

7 years, 7 months

1
0
0 0

+ gup-return-efault-on-access_ok-failure.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: get_user_pages_fast(): return -EFAULT on access_ok failure has been added to the -mm tree. Its filename is gup-return-efault-on-access_ok-failure.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/gup-return-efault-on-access_ok-fai… and later at http://ozlabs.org/~akpm/mmotm/broken-out/gup-return-efault-on-access_ok-fai… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: "Michael S. Tsirkin" <mst(a)redhat.com> Subject: get_user_pages_fast(): return -EFAULT on access_ok failure get_user_pages_fast is supposed to be a faster drop-in equivalent of get_user_pages. As such, callers expect it to return a negative return code when passed an invalid address, and never expect it to return 0 when passed a positive number of pages, since its documentation says: * Returns number of pages pinned. This may be fewer than the number * requested. If nr_pages is 0 or negative, returns 0. If no pages * were pinned, returns -errno. When get_user_pages_fast fall back on get_user_pages this is exactly what happens. Unfortunately the implementation is inconsistent: it returns 0 if passed a kernel address, confusing callers: for example, the following is pretty common but does not appear to do the right thing with a kernel address: ret = get_user_pages_fast(addr, 1, writeable, &page); if (ret < 0) return ret; Change get_user_pages_fast to return -EFAULT when supplied a kernel address to make it match expectations. All callers have been audited for consistency with the documented semantics. Link: http://lkml.kernel.org/r/1522962072-182137-4-git-send-email-mst@redhat.com Fixes: 5b65c4677a57 ("mm, x86/mm: Fix performance regression in get_user_pages_fast()") Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Reported-by: syzbot+6304bf97ef436580fede(a)syzkaller.appspotmail.com Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Huang Ying <ying.huang(a)intel.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Thorsten Leemhuis <regressions(a)leemhuis.info> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/gup.c~gup-return-efault-on-access_ok-failure mm/gup.c --- a/mm/gup.c~gup-return-efault-on-access_ok-failure +++ a/mm/gup.c @@ -1806,9 +1806,12 @@ int get_user_pages_fast(unsigned long st len = (unsigned long) nr_pages << PAGE_SHIFT; end = start + len; + if (nr_pages <= 0) + return 0; + if (unlikely(!access_ok(write ? VERIFY_WRITE : VERIFY_READ, (void __user *)start, len))) - return 0; + return -EFAULT; if (gup_fast_permitted(start, nr_pages, write)) { local_irq_disable(); _ Patches currently in -mm which might be from mst(a)redhat.com are mm-gup_benchmark-handle-gup-failures.patch gup-return-efault-on-access_ok-failure.patch mm-gup-document-return-value.patch

7 years, 7 months

1
0
0 0

+ mm-gup_benchmark-handle-gup-failures-fix.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm-gup_benchmark-handle-gup-failures-fix has been added to the -mm tree. Its filename is mm-gup_benchmark-handle-gup-failures-fix.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-gup_benchmark-handle-gup-failur… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-gup_benchmark-handle-gup-failur… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Andrew Morton <akpm(a)linux-foundation.org> Subject: mm-gup_benchmark-handle-gup-failures-fix Cc: Huang Ying <ying.huang(a)intel.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: "Michael S. Tsirkin" <mst(a)redhat.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: <stable(a)vger.kernel.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Thorsten Leemhuis <regressions(a)leemhuis.info> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/gup_benchmark.c~mm-gup_benchmark-handle-gup-failures-fix mm/gup_benchmark.c --- a/mm/gup_benchmark.c~mm-gup_benchmark-handle-gup-failures-fix +++ a/mm/gup_benchmark.c @@ -41,8 +41,9 @@ static int __gup_benchmark_ioctl(unsigne } nr = get_user_pages_fast(addr, nr, gup->flags & 1, pages + i); - if (nr > 0) - i += nr; + if (nr <= 0) + break; + i += nr; } end_time = ktime_get(); _ Patches currently in -mm which might be from akpm(a)linux-foundation.org are i-need-old-gcc.patch mm-gup_benchmark-handle-gup-failures-fix.patch arm-arch-arm-include-asm-pageh-needs-personalityh.patch ocfs2-without-quota-support-try-to-avoid-calling-quota-recovery-checkpatch-fixes.patch mm.patch z3fold-fix-memory-leak-fix.patch list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix.patch mm-oom-cgroup-aware-oom-killer-fix.patch mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix-2-fix.patch proc-add-seq_put_decimal_ull_width-to-speed-up-proc-pid-smaps-fix.patch fs-reiserfs-journalc-add-missing-resierfs_warning-arg.patch ipc-shmc-shm_split-remove-unneeded-test-for-null-shm_file_datavm_ops.patch linux-next-rejects.patch linux-next-git-rejects.patch linux-next-fixup.patch fs-fsnotify-account-fsnotify-metadata-to-kmemcg-fix.patch kernel-forkc-export-kernel_thread-to-modules.patch slab-leaks3-default-y.patch

7 years, 7 months

1
0
0 0

+ mm-gup_benchmark-handle-gup-failures.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/gup_benchmark: handle gup failures has been added to the -mm tree. Its filename is mm-gup_benchmark-handle-gup-failures.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-gup_benchmark-handle-gup-failur… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-gup_benchmark-handle-gup-failur… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: "Michael S. Tsirkin" <mst(a)redhat.com> Subject: mm/gup_benchmark: handle gup failures Patch series "mm/get_user_pages_fast fixes, cleanups", v2. Turns out get_user_pages_fast and __get_user_pages_fast return different values on error when given a single page: __get_user_pages_fast returns 0. get_user_pages_fast returns either 0 or an error. Callers of get_user_pages_fast expect an error so fix it up to return an error consistently. Stress the difference between get_user_pages_fast and __get_user_pages_fast to make sure callers aren't confused. This patch (of 3): __gup_benchmark_ioctl does not handle the case where get_user_pages_fast fails: - a negative return code will cause a buffer overrun - returning with partial success will cause use of uninitialized memory. Link: http://lkml.kernel.org/r/1522962072-182137-3-git-send-email-mst@redhat.com Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Huang Ying <ying.huang(a)intel.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Thorsten Leemhuis <regressions(a)leemhuis.info> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/gup_benchmark.c~mm-gup_benchmark-handle-gup-failures mm/gup_benchmark.c --- a/mm/gup_benchmark.c~mm-gup_benchmark-handle-gup-failures +++ a/mm/gup_benchmark.c @@ -23,7 +23,7 @@ static int __gup_benchmark_ioctl(unsigne struct page **pages; nr_pages = gup->size / PAGE_SIZE; - pages = kvmalloc(sizeof(void *) * nr_pages, GFP_KERNEL); + pages = kvzalloc(sizeof(void *) * nr_pages, GFP_KERNEL); if (!pages) return -ENOMEM; @@ -41,7 +41,8 @@ static int __gup_benchmark_ioctl(unsigne } nr = get_user_pages_fast(addr, nr, gup->flags & 1, pages + i); - i += nr; + if (nr > 0) + i += nr; } end_time = ktime_get(); _ Patches currently in -mm which might be from mst(a)redhat.com are mm-gup_benchmark-handle-gup-failures.patch gup-return-efault-on-access_ok-failure.patch mm-gup-document-return-value.patch

7 years, 7 months

1
0
0 0

[PATCH v2 1/3] mm/gup_benchmark: handle gup failures

by Michael S. Tsirkin

__gup_benchmark_ioctl does not handle the case where get_user_pages_fast fails: - a negative return code will cause a buffer overrun - returning with partial success will cause use of uninitialized memory. Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Huang Ying <ying.huang(a)intel.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Thorsten Leemhuis <regressions(a)leemhuis.info> Cc: stable(a)vger.kernel.org Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> --- mm/gup_benchmark.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/mm/gup_benchmark.c b/mm/gup_benchmark.c index 5c8e2ab..d743035 100644 --- a/mm/gup_benchmark.c +++ b/mm/gup_benchmark.c @@ -23,7 +23,7 @@ static int __gup_benchmark_ioctl(unsigned int cmd, struct page **pages; nr_pages = gup->size / PAGE_SIZE; - pages = kvmalloc(sizeof(void *) * nr_pages, GFP_KERNEL); + pages = kvzalloc(sizeof(void *) * nr_pages, GFP_KERNEL); if (!pages) return -ENOMEM; @@ -41,7 +41,8 @@ static int __gup_benchmark_ioctl(unsigned int cmd, } nr = get_user_pages_fast(addr, nr, gup->flags & 1, pages + i); - i += nr; + if (nr > 0) + i += nr; } end_time = ktime_get(); -- MST

7 years, 7 months

3
3
0 0

+ resource-fix-integer-overflow-at-reallocation.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: resource: fix integer overflow at reallocation has been added to the -mm tree. Its filename is resource-fix-integer-overflow-at-reallocation.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/resource-fix-integer-overflow-at-r… and later at http://ozlabs.org/~akpm/mmotm/broken-out/resource-fix-integer-overflow-at-r… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Takashi Iwai <tiwai(a)suse.de> Subject: resource: fix integer overflow at reallocation We've got a bug report indicating a kernel panic at booting on an x86-32 system, and it turned out to be the invalid resource assigned after PCI resource reallocation. __find_resource() first aligns the resource start address and resets the end address with start+size-1 accordingly, then checks whether it's contained. Here the end address may overflow the integer, although resource_contains() still returns true because the function validates only start and end address. So this ends up with returning an invalid resource (start > end). There was already an attempt to cover such a problem in the commit 47ea91b4052d ("Resource: fix wrong resource window calculation"), but this case is an overseen one. This patch adds the validity check in resource_contains() to see whether the given resource has a valid range for avoiding the integer overflow problem. Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1086739 Link: http://lkml.kernel.org/r/20180408072026.27365-1-tiwai@suse.de Fixes: 23c570a67448 ("resource: ability to resize an allocated resource") Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Reported-by: Michael Henders <hendersm(a)shaw.ca> Tested-by: Michael Henders <hendersm(a)shaw.ca> Reviewed-by: Ram Pai <linuxram(a)us.ibm.com> Cc: Bjorn Helgaas <bhelgaas(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN include/linux/ioport.h~resource-fix-integer-overflow-at-reallocation include/linux/ioport.h --- a/include/linux/ioport.h~resource-fix-integer-overflow-at-reallocation +++ a/include/linux/ioport.h @@ -212,6 +212,9 @@ static inline bool resource_contains(str return false; if (r1->flags & IORESOURCE_UNSET || r2->flags & IORESOURCE_UNSET) return false; + /* sanity check whether it's a valid resource range */ + if (r2->end < r2->start) + return false; return r1->start <= r2->start && r1->end >= r2->end; } _ Patches currently in -mm which might be from tiwai(a)suse.de are resource-fix-integer-overflow-at-reallocation.patch

7 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror