This is a note to let you know that I've just added the patch titled
IB/uverbs: Improve lockdep_check
to the 4.15-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:
ib-uverbs-improve-lockdep_check.patch
and it can be found in the queue-4.15 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 104f268d439b3c21c83708e52946a4d8d37f3d0f Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe <jgg(a)mellanox.com>
Date: Tue, 13 Feb 2018 12:18:38 +0200
Subject: IB/uverbs: Improve lockdep_check
From: Jason Gunthorpe <jgg(a)mellanox.com>
commit 104f268d439b3c21c83708e52946a4d8d37f3d0f upstream.
This is really being used as an assert that the expected usecnt
is being held and implicitly that the usecnt is valid. Rename it to
assert_uverbs_usecnt and tighten the checks to only accept valid
values of usecnt (eg 0 and < -1 are invalid).
The tigher checkes make the assertion cover more cases and is more
likely to find bugs via syzkaller/etc.
Fixes: 3832125624b7 ("IB/core: Add support for idr types")
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/rdma_core.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/infiniband/core/rdma_core.c
+++ b/drivers/infiniband/core/rdma_core.c
@@ -407,13 +407,13 @@ static int __must_check remove_commit_fd
return ret;
}
-static void lockdep_check(struct ib_uobject *uobj, bool exclusive)
+static void assert_uverbs_usecnt(struct ib_uobject *uobj, bool exclusive)
{
#ifdef CONFIG_LOCKDEP
if (exclusive)
- WARN_ON(atomic_read(&uobj->usecnt) > 0);
+ WARN_ON(atomic_read(&uobj->usecnt) != -1);
else
- WARN_ON(atomic_read(&uobj->usecnt) == -1);
+ WARN_ON(atomic_read(&uobj->usecnt) <= 0);
#endif
}
@@ -452,7 +452,7 @@ int __must_check rdma_remove_commit_uobj
WARN(true, "ib_uverbs: Cleanup is running while removing an uobject\n");
return 0;
}
- lockdep_check(uobj, true);
+ assert_uverbs_usecnt(uobj, true);
ret = _rdma_remove_commit_uobject(uobj, RDMA_REMOVE_DESTROY);
up_read(&ucontext->cleanup_rwsem);
@@ -482,7 +482,7 @@ int rdma_explicit_destroy(struct ib_uobj
WARN(true, "ib_uverbs: Cleanup is running while removing an uobject\n");
return 0;
}
- lockdep_check(uobject, true);
+ assert_uverbs_usecnt(uobject, true);
ret = uobject->type->type_class->remove_commit(uobject,
RDMA_REMOVE_DESTROY);
if (ret)
@@ -569,7 +569,7 @@ static void lookup_put_fd_uobject(struct
void rdma_lookup_put_uobject(struct ib_uobject *uobj, bool exclusive)
{
- lockdep_check(uobj, exclusive);
+ assert_uverbs_usecnt(uobj, exclusive);
uobj->type->type_class->lookup_put(uobj, exclusive);
/*
* In order to unlock an object, either decrease its usecnt for
Patches currently in stable-queue which might be from jgg(a)mellanox.com are
queue-4.15/ib-uverbs-improve-lockdep_check.patch
This is a note to let you know that I've just added the patch titled
mac80211_hwsim: don't use WQ_MEM_RECLAIM
to the 4.15-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:
mac80211_hwsim-don-t-use-wq_mem_reclaim.patch
and it can be found in the queue-4.15 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 ce162bfbc0b601841886965baba14877127c7c7c Mon Sep 17 00:00:00 2001
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Wed, 24 Jan 2018 08:40:51 +0100
Subject: mac80211_hwsim: don't use WQ_MEM_RECLAIM
From: Johannes Berg <johannes.berg(a)intel.com>
commit ce162bfbc0b601841886965baba14877127c7c7c upstream.
We're obviously not part of a memory reclaim path, so don't set the flag.
This also causes a warning in check_flush_dependency() since we end up
in a code path that flushes a non-reclaim workqueue, and we shouldn't do
that if we were really part of reclaim.
Reported-by: syzbot+41cdaf4232c50e658934(a)syzkaller.appspotmail.com
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/mac80211_hwsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3455,7 +3455,7 @@ static int __init init_mac80211_hwsim(vo
spin_lock_init(&hwsim_radio_lock);
- hwsim_wq = alloc_workqueue("hwsim_wq",WQ_MEM_RECLAIM,0);
+ hwsim_wq = alloc_workqueue("hwsim_wq", 0, 0);
if (!hwsim_wq)
return -ENOMEM;
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.15/mac80211_hwsim-don-t-use-wq_mem_reclaim.patch
This is a note to let you know that I've just added the patch titled
bpf: cpumap: use GFP_KERNEL instead of GFP_ATOMIC in __cpu_map_entry_alloc()
to the 4.15-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:
bpf-cpumap-use-gfp_kernel-instead-of-gfp_atomic-in-__cpu_map_entry_alloc.patch
and it can be found in the queue-4.15 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 7fc17e909edfb9bf421ee04e981d3d474175c7c7 Mon Sep 17 00:00:00 2001
From: Jason Wang <jasowang(a)redhat.com>
Date: Wed, 14 Feb 2018 22:17:34 +0800
Subject: bpf: cpumap: use GFP_KERNEL instead of GFP_ATOMIC in __cpu_map_entry_alloc()
From: Jason Wang <jasowang(a)redhat.com>
commit 7fc17e909edfb9bf421ee04e981d3d474175c7c7 upstream.
There're several implications after commit 0bf7800f1799 ("ptr_ring:
try vmalloc() when kmalloc() fails") with the using of vmalloc() since
can't allow GFP_ATOMIC but mandate GFP_KERNEL. This will lead a WARN
since cpumap try to call with GFP_ATOMIC. Fortunately, entry
allocation of cpumap can only be done through syscall path which means
GFP_ATOMIC is not necessary, so fixing this by replacing GFP_ATOMIC
with GFP_KERNEL.
Reported-by: syzbot+1a240cdb1f4cc88819df(a)syzkaller.appspotmail.com
Fixes: 0bf7800f1799 ("ptr_ring: try vmalloc() when kmalloc() fails")
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Daniel Borkmann <daniel(a)iogearbox.net>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Jesper Dangaard Brouer <brouer(a)redhat.com>
Cc: akpm(a)linux-foundation.org
Cc: dhowells(a)redhat.com
Cc: hannes(a)cmpxchg.org
Signed-off-by: Jason Wang <jasowang(a)redhat.com>
Acked-by: Jesper Dangaard Brouer <brouer(a)redhat.com>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/bpf/cpumap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/bpf/cpumap.c
+++ b/kernel/bpf/cpumap.c
@@ -339,7 +339,7 @@ static int cpu_map_kthread_run(void *dat
struct bpf_cpu_map_entry *__cpu_map_entry_alloc(u32 qsize, u32 cpu, int map_id)
{
- gfp_t gfp = GFP_ATOMIC|__GFP_NOWARN;
+ gfp_t gfp = GFP_KERNEL | __GFP_NOWARN;
struct bpf_cpu_map_entry *rcpu;
int numa, err;
Patches currently in stable-queue which might be from jasowang(a)redhat.com are
queue-4.15/bpf-cpumap-use-gfp_kernel-instead-of-gfp_atomic-in-__cpu_map_entry_alloc.patch
This is a note to let you know that I've just added the patch titled
IB/uverbs: Improve lockdep_check
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:
ib-uverbs-improve-lockdep_check.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 104f268d439b3c21c83708e52946a4d8d37f3d0f Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe <jgg(a)mellanox.com>
Date: Tue, 13 Feb 2018 12:18:38 +0200
Subject: IB/uverbs: Improve lockdep_check
From: Jason Gunthorpe <jgg(a)mellanox.com>
commit 104f268d439b3c21c83708e52946a4d8d37f3d0f upstream.
This is really being used as an assert that the expected usecnt
is being held and implicitly that the usecnt is valid. Rename it to
assert_uverbs_usecnt and tighten the checks to only accept valid
values of usecnt (eg 0 and < -1 are invalid).
The tigher checkes make the assertion cover more cases and is more
likely to find bugs via syzkaller/etc.
Fixes: 3832125624b7 ("IB/core: Add support for idr types")
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/rdma_core.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/infiniband/core/rdma_core.c
+++ b/drivers/infiniband/core/rdma_core.c
@@ -407,13 +407,13 @@ static int __must_check remove_commit_fd
return ret;
}
-static void lockdep_check(struct ib_uobject *uobj, bool exclusive)
+static void assert_uverbs_usecnt(struct ib_uobject *uobj, bool exclusive)
{
#ifdef CONFIG_LOCKDEP
if (exclusive)
- WARN_ON(atomic_read(&uobj->usecnt) > 0);
+ WARN_ON(atomic_read(&uobj->usecnt) != -1);
else
- WARN_ON(atomic_read(&uobj->usecnt) == -1);
+ WARN_ON(atomic_read(&uobj->usecnt) <= 0);
#endif
}
@@ -452,7 +452,7 @@ int __must_check rdma_remove_commit_uobj
WARN(true, "ib_uverbs: Cleanup is running while removing an uobject\n");
return 0;
}
- lockdep_check(uobj, true);
+ assert_uverbs_usecnt(uobj, true);
ret = _rdma_remove_commit_uobject(uobj, RDMA_REMOVE_DESTROY);
up_read(&ucontext->cleanup_rwsem);
@@ -482,7 +482,7 @@ int rdma_explicit_destroy(struct ib_uobj
WARN(true, "ib_uverbs: Cleanup is running while removing an uobject\n");
return 0;
}
- lockdep_check(uobject, true);
+ assert_uverbs_usecnt(uobject, true);
ret = uobject->type->type_class->remove_commit(uobject,
RDMA_REMOVE_DESTROY);
if (ret)
@@ -569,7 +569,7 @@ static void lookup_put_fd_uobject(struct
void rdma_lookup_put_uobject(struct ib_uobject *uobj, bool exclusive)
{
- lockdep_check(uobj, exclusive);
+ assert_uverbs_usecnt(uobj, exclusive);
uobj->type->type_class->lookup_put(uobj, exclusive);
/*
* In order to unlock an object, either decrease its usecnt for
Patches currently in stable-queue which might be from jgg(a)mellanox.com are
queue-4.14/ib-uverbs-improve-lockdep_check.patch
This is a note to let you know that I've just added the patch titled
RDMA/mlx5: Fix integer overflow while resizing CQ
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:
rdma-mlx5-fix-integer-overflow-while-resizing-cq.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 28e9091e3119933c38933cb8fc48d5618eb784c8 Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Wed, 7 Mar 2018 15:29:09 +0200
Subject: RDMA/mlx5: Fix integer overflow while resizing CQ
From: Leon Romanovsky <leonro(a)mellanox.com>
commit 28e9091e3119933c38933cb8fc48d5618eb784c8 upstream.
The user can provide very large cqe_size which will cause to integer
overflow as it can be seen in the following UBSAN warning:
=======================================================================
UBSAN: Undefined behaviour in drivers/infiniband/hw/mlx5/cq.c:1192:53
signed integer overflow:
64870 * 65536 cannot be represented in type 'int'
CPU: 0 PID: 267 Comm: syzkaller605279 Not tainted 4.15.0+ #90 Hardware
name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
Call Trace:
dump_stack+0xde/0x164
? dma_virt_map_sg+0x22c/0x22c
ubsan_epilogue+0xe/0x81
handle_overflow+0x1f3/0x251
? __ubsan_handle_negate_overflow+0x19b/0x19b
? lock_acquire+0x440/0x440
mlx5_ib_resize_cq+0x17e7/0x1e40
? cyc2ns_read_end+0x10/0x10
? native_read_msr_safe+0x6c/0x9b
? cyc2ns_read_end+0x10/0x10
? mlx5_ib_modify_cq+0x220/0x220
? sched_clock_cpu+0x18/0x200
? lookup_get_idr_uobject+0x200/0x200
? rdma_lookup_get_uobject+0x145/0x2f0
ib_uverbs_resize_cq+0x207/0x3e0
? ib_uverbs_ex_create_cq+0x250/0x250
ib_uverbs_write+0x7f9/0xef0
? cyc2ns_read_end+0x10/0x10
? print_irqtrace_events+0x280/0x280
? ib_uverbs_ex_create_cq+0x250/0x250
? uverbs_devnode+0x110/0x110
? sched_clock_cpu+0x18/0x200
? do_raw_spin_trylock+0x100/0x100
? __lru_cache_add+0x16e/0x290
__vfs_write+0x10d/0x700
? uverbs_devnode+0x110/0x110
? kernel_read+0x170/0x170
? sched_clock_cpu+0x18/0x200
? security_file_permission+0x93/0x260
vfs_write+0x1b0/0x550
SyS_write+0xc7/0x1a0
? SyS_read+0x1a0/0x1a0
? trace_hardirqs_on_thunk+0x1a/0x1c
entry_SYSCALL_64_fastpath+0x1e/0x8b
RIP: 0033:0x433549
RSP: 002b:00007ffe63bd1ea8 EFLAGS: 00000217
=======================================================================
Cc: syzkaller <syzkaller(a)googlegroups.com>
Cc: <stable(a)vger.kernel.org> # 3.13
Fixes: bde51583f49b ("IB/mlx5: Add support for resize CQ")
Reported-by: Noa Osherovich <noaos(a)mellanox.com>
Reviewed-by: Yishai Hadas <yishaih(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
index b5cfdaa9c7c8..15457c9569a7 100644
--- a/drivers/infiniband/hw/mlx5/cq.c
+++ b/drivers/infiniband/hw/mlx5/cq.c
@@ -1178,7 +1178,12 @@ static int resize_user(struct mlx5_ib_dev *dev, struct mlx5_ib_cq *cq,
if (ucmd.reserved0 || ucmd.reserved1)
return -EINVAL;
- umem = ib_umem_get(context, ucmd.buf_addr, entries * ucmd.cqe_size,
+ /* check multiplication overflow */
+ if (ucmd.cqe_size && SIZE_MAX / ucmd.cqe_size <= entries - 1)
+ return -EINVAL;
+
+ umem = ib_umem_get(context, ucmd.buf_addr,
+ (size_t)ucmd.cqe_size * entries,
IB_ACCESS_LOCAL_WRITE, 1);
if (IS_ERR(umem)) {
err = PTR_ERR(umem);
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.14/rdma-ucma-limit-possible-option-size.patch
queue-4.14/rdma-ucma-check-that-user-doesn-t-overflow-qp-state.patch
queue-4.14/rdma-mlx5-fix-integer-overflow-while-resizing-cq.patch
This is a note to let you know that I've just added the patch titled
RDMA/ucma: Check that user doesn't overflow QP state
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:
rdma-ucma-check-that-user-doesn-t-overflow-qp-state.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 a5880b84430316e3e1c1f5d23aa32ec6000cc717 Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Wed, 7 Mar 2018 18:49:16 +0200
Subject: RDMA/ucma: Check that user doesn't overflow QP state
From: Leon Romanovsky <leonro(a)mellanox.com>
commit a5880b84430316e3e1c1f5d23aa32ec6000cc717 upstream.
The QP state is limited and declared in enum ib_qp_state,
but ucma user was able to supply any possible (u32) value.
Reported-by: syzbot+0df1ab766f8924b1edba(a)syzkaller.appspotmail.com
Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/ucma.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -1148,6 +1148,9 @@ static ssize_t ucma_init_qp_attr(struct
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
+ if (cmd.qp_state > IB_QPS_ERR)
+ return -EINVAL;
+
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.14/rdma-ucma-limit-possible-option-size.patch
queue-4.14/rdma-ucma-check-that-user-doesn-t-overflow-qp-state.patch
queue-4.14/rdma-mlx5-fix-integer-overflow-while-resizing-cq.patch