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

Patch "xfrm: Fix stack-out-of-bounds read on socket policy lookup." 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 xfrm: Fix stack-out-of-bounds read on socket policy lookup. 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: xfrm-fix-stack-out-of-bounds-read-on-socket-policy-lookup.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 ddc47e4404b58f03e98345398fb12d38fe291512 Mon Sep 17 00:00:00 2001 From: Steffen Klassert <steffen.klassert(a)secunet.com> Date: Wed, 29 Nov 2017 06:53:55 +0100 Subject: xfrm: Fix stack-out-of-bounds read on socket policy lookup. From: Steffen Klassert <steffen.klassert(a)secunet.com> commit ddc47e4404b58f03e98345398fb12d38fe291512 upstream. When we do tunnel or beet mode, we pass saddr and daddr from the template to xfrm_state_find(), this is ok. On transport mode, we pass the addresses from the flowi, assuming that the IP addresses (and address family) don't change during transformation. This assumption is wrong in the IPv4 mapped IPv6 case, packet is IPv4 and template is IPv6. Fix this by catching address family missmatches of the policy and the flow already before we do the lookup. Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/xfrm/xfrm_policy.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -1257,9 +1257,15 @@ static struct xfrm_policy *xfrm_sk_polic again: pol = rcu_dereference(sk->sk_policy[dir]); if (pol != NULL) { - bool match = xfrm_selector_match(&pol->selector, fl, family); + bool match; int err = 0; + if (pol->family != family) { + pol = NULL; + goto out; + } + + match = xfrm_selector_match(&pol->selector, fl, family); if (match) { if ((sk->sk_mark & pol->mark.m) != pol->mark.v) { pol = NULL; Patches currently in stable-queue which might be from steffen.klassert(a)secunet.com are queue-4.9/xfrm-fix-stack-out-of-bounds-read-on-socket-policy-lookup.patch queue-4.9/xfrm-skip-policies-marked-as-dead-while-rehashing.patch queue-4.9/xfrm-check-id-proto-in-validate_tmpl.patch

7 years, 4 months

1
0
0 0

Patch "xfrm: check id proto in validate_tmpl()" 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 xfrm: check id proto in validate_tmpl() 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: xfrm-check-id-proto-in-validate_tmpl.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 6a53b7593233ab9e4f96873ebacc0f653a55c3e1 Mon Sep 17 00:00:00 2001 From: Cong Wang <xiyou.wangcong(a)gmail.com> Date: Mon, 27 Nov 2017 11:15:16 -0800 Subject: xfrm: check id proto in validate_tmpl() From: Cong Wang <xiyou.wangcong(a)gmail.com> commit 6a53b7593233ab9e4f96873ebacc0f653a55c3e1 upstream. syzbot reported a kernel warning in xfrm_state_fini(), which indicates that we have entries left in the list net->xfrm.state_all whose proto is zero. And xfrm_id_proto_match() doesn't consider them as a match with IPSEC_PROTO_ANY in this case. Proto with value 0 is probably not a valid value, at least verify_newsa_info() doesn't consider it valid either. This patch fixes it by checking the proto value in validate_tmpl() and rejecting invalid ones, like what iproute2 does in xfrm_xfrmproto_getbyname(). Reported-by: syzbot <syzkaller(a)googlegroups.com> Cc: Steffen Klassert <steffen.klassert(a)secunet.com> Cc: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/xfrm/xfrm_user.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -1406,6 +1406,21 @@ static int validate_tmpl(int nr, struct default: return -EINVAL; } + + switch (ut[i].id.proto) { + case IPPROTO_AH: + case IPPROTO_ESP: + case IPPROTO_COMP: +#if IS_ENABLED(CONFIG_IPV6) + case IPPROTO_ROUTING: + case IPPROTO_DSTOPTS: +#endif + case IPSEC_PROTO_ANY: + break; + default: + return -EINVAL; + } + } return 0; Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are queue-4.9/netfilter-xt_cgroup-initialize-info-priv-in-cgroup_mt_check_v1.patch queue-4.9/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch queue-4.9/xfrm-check-id-proto-in-validate_tmpl.patch

7 years, 4 months

1
0
0 0

Patch "vhost: use mutex_lock_nested() in vhost_dev_lock_vqs()" 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 vhost: use mutex_lock_nested() in vhost_dev_lock_vqs() 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: vhost-use-mutex_lock_nested-in-vhost_dev_lock_vqs.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 e9cb4239134c860e5f92c75bf5321bd377bb505b Mon Sep 17 00:00:00 2001 From: Jason Wang <jasowang(a)redhat.com> Date: Tue, 23 Jan 2018 17:27:25 +0800 Subject: vhost: use mutex_lock_nested() in vhost_dev_lock_vqs() From: Jason Wang <jasowang(a)redhat.com> commit e9cb4239134c860e5f92c75bf5321bd377bb505b upstream. We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to hold mutexes of all virtqueues. This may confuse lockdep to report a possible deadlock because of trying to hold locks belong to same class. Switch to use mutex_lock_nested() to avoid false positive. Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") Reported-by: syzbot+dbb7c1161485e61b0241(a)syzkaller.appspotmail.com Signed-off-by: Jason Wang <jasowang(a)redhat.com> Acked-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/vhost/vhost.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -849,7 +849,7 @@ static void vhost_dev_lock_vqs(struct vh { int i = 0; for (i = 0; i < d->nvqs; ++i) - mutex_lock(&d->vqs[i]->mutex); + mutex_lock_nested(&d->vqs[i]->mutex, i); } static void vhost_dev_unlock_vqs(struct vhost_dev *d) Patches currently in stable-queue which might be from jasowang(a)redhat.com are queue-4.9/vhost-use-mutex_lock_nested-in-vhost_dev_lock_vqs.patch queue-4.9/ptr_ring-fail-early-if-queue-occupies-more-than-kmalloc_max_size.patch

7 years, 4 months

1
0
0 0

Patch "staging: android: ion: Add __GFP_NOWARN for system contig heap" 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 staging: android: ion: Add __GFP_NOWARN for system contig heap 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: staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.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 0c75f10312a35b149b2cebb1832316b35c2337ca Mon Sep 17 00:00:00 2001 From: Laura Abbott <labbott(a)redhat.com> Date: Fri, 5 Jan 2018 11:14:08 -0800 Subject: staging: android: ion: Add __GFP_NOWARN for system contig heap From: Laura Abbott <labbott(a)redhat.com> commit 0c75f10312a35b149b2cebb1832316b35c2337ca upstream. syzbot reported a warning from Ion: WARNING: CPU: 1 PID: 3485 at mm/page_alloc.c:3926 ... __alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252 alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036 alloc_pages include/linux/gfp.h:492 [inline] ion_system_contig_heap_allocate+0x40/0x2c0 drivers/staging/android/ion/ion_system_heap.c:374 ion_buffer_create drivers/staging/android/ion/ion.c:93 [inline] ion_alloc+0x2c1/0x9e0 drivers/staging/android/ion/ion.c:420 ion_ioctl+0x26d/0x380 drivers/staging/android/ion/ion-ioctl.c:84 vfs_ioctl fs/ioctl.c:46 [inline] do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686 SYSC_ioctl fs/ioctl.c:701 [inline] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692 This is a warning about attempting to allocate order > MAX_ORDER. This is coming from a userspace Ion allocation request. Since userspace is free to request however much memory it wants (and the kernel is free to deny its allocation), silence the allocation attempt with __GFP_NOWARN in case it fails. Reported-by: syzbot+76e7efc4748495855a4d(a)syzkaller.appspotmail.com Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Laura Abbott <labbott(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/android/ion/ion_system_heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/staging/android/ion/ion_system_heap.c +++ b/drivers/staging/android/ion/ion_system_heap.c @@ -384,7 +384,7 @@ static int ion_system_contig_heap_alloca if (align > (PAGE_SIZE << order)) return -EINVAL; - page = alloc_pages(low_order_gfp_flags, order); + page = alloc_pages(low_order_gfp_flags | __GFP_NOWARN, order); if (!page) return -ENOMEM; Patches currently in stable-queue which might be from labbott(a)redhat.com are queue-4.9/staging-android-ion-switch-from-warn-to-pr_warn.patch queue-4.9/staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.patch

7 years, 4 months

1
0
0 0

Patch "staging: android: ion: Switch from WARN to pr_warn" 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 staging: android: ion: Switch from WARN to pr_warn 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: staging-android-ion-switch-from-warn-to-pr_warn.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 e4e179a844f52e907e550f887d0a2171f1508af1 Mon Sep 17 00:00:00 2001 From: Laura Abbott <labbott(a)redhat.com> Date: Fri, 5 Jan 2018 11:14:09 -0800 Subject: staging: android: ion: Switch from WARN to pr_warn From: Laura Abbott <labbott(a)redhat.com> commit e4e179a844f52e907e550f887d0a2171f1508af1 upstream. Syzbot reported a warning with Ion: WARNING: CPU: 0 PID: 3502 at drivers/staging/android/ion/ion-ioctl.c:73 ion_ioctl+0x2db/0x380 drivers/staging/android/ion/ion-ioctl.c:73 Kernel panic - not syncing: panic_on_warn set ... This is a warning that validation of the ioctl fields failed. This was deliberately added as a warning to make it very obvious to developers that something needed to be fixed. In reality, this is overkill and disturbs fuzzing. Switch to pr_warn for a message instead. Reported-by: syzbot+fa2d5f63ee5904a0115a(a)syzkaller.appspotmail.com Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Laura Abbott <labbott(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/android/ion/ion-ioctl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/staging/android/ion/ion-ioctl.c +++ b/drivers/staging/android/ion/ion-ioctl.c @@ -83,8 +83,10 @@ long ion_ioctl(struct file *filp, unsign return -EFAULT; ret = validate_ioctl_arg(cmd, &data); - if (WARN_ON_ONCE(ret)) + if (ret) { + pr_warn_once("%s: ioctl validate failed\n", __func__); return ret; + } if (!(dir & _IOC_WRITE)) memset(&data, 0, sizeof(data)); Patches currently in stable-queue which might be from labbott(a)redhat.com are queue-4.9/staging-android-ion-switch-from-warn-to-pr_warn.patch queue-4.9/staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.patch

7 years, 4 months

1
0
0 0

Patch "selinux: skip bounded transition processing if the policy isn't loaded" 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 selinux: skip bounded transition processing if the policy isn't loaded 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: selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.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 4b14752ec4e0d87126e636384cf37c8dd9df157c Mon Sep 17 00:00:00 2001 From: Paul Moore <paul(a)paul-moore.com> Date: Tue, 5 Dec 2017 17:17:43 -0500 Subject: selinux: skip bounded transition processing if the policy isn't loaded From: Paul Moore <paul(a)paul-moore.com> commit 4b14752ec4e0d87126e636384cf37c8dd9df157c upstream. We can't do anything reasonable in security_bounded_transition() if we don't have a policy loaded, and in fact we could run into problems with some of the code inside expecting a policy. Fix these problems like we do many others in security/selinux/ss/services.c by checking to see if the policy is loaded (ss_initialized) and returning quickly if it isn't. Reported-by: syzbot <syzkaller-bugs(a)googlegroups.com> Signed-off-by: Paul Moore <paul(a)paul-moore.com> Acked-by: Stephen Smalley <sds(a)tycho.nsa.gov> Reviewed-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/selinux/ss/services.c | 3 +++ 1 file changed, 3 insertions(+) --- a/security/selinux/ss/services.c +++ b/security/selinux/ss/services.c @@ -854,6 +854,9 @@ int security_bounded_transition(u32 old_ int index; int rc; + if (!ss_initialized) + return 0; + read_lock(&policy_rwlock); rc = -EINVAL; Patches currently in stable-queue which might be from paul(a)paul-moore.com are queue-4.9/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch queue-4.9/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch

7 years, 4 months

1
0
0 0

Patch "selinux: ensure the context is NUL terminated in security_context_to_sid_core()" 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 selinux: ensure the context is NUL terminated in security_context_to_sid_core() 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: selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.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 ef28df55ac27e1e5cd122e19fa311d886d47a756 Mon Sep 17 00:00:00 2001 From: Paul Moore <paul(a)paul-moore.com> Date: Tue, 28 Nov 2017 18:51:12 -0500 Subject: selinux: ensure the context is NUL terminated in security_context_to_sid_core() From: Paul Moore <paul(a)paul-moore.com> commit ef28df55ac27e1e5cd122e19fa311d886d47a756 upstream. The syzbot/syzkaller automated tests found a problem in security_context_to_sid_core() during early boot (before we load the SELinux policy) where we could potentially feed context strings without NUL terminators into the strcmp() function. We already guard against this during normal operation (after the SELinux policy has been loaded) by making a copy of the context strings and explicitly adding a NUL terminator to the end. The patch extends this protection to the early boot case (no loaded policy) by moving the context copy earlier in security_context_to_sid_core(). Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Paul Moore <paul(a)paul-moore.com> Reviewed-By: William Roberts <william.c.roberts(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/selinux/ss/services.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) --- a/security/selinux/ss/services.c +++ b/security/selinux/ss/services.c @@ -1400,27 +1400,25 @@ static int security_context_to_sid_core( if (!scontext_len) return -EINVAL; + /* Copy the string to allow changes and ensure a NUL terminator */ + scontext2 = kmemdup_nul(scontext, scontext_len, gfp_flags); + if (!scontext2) + return -ENOMEM; + if (!ss_initialized) { int i; for (i = 1; i < SECINITSID_NUM; i++) { - if (!strcmp(initial_sid_to_string[i], scontext)) { + if (!strcmp(initial_sid_to_string[i], scontext2)) { *sid = i; - return 0; + goto out; } } *sid = SECINITSID_KERNEL; - return 0; + goto out; } *sid = SECSID_NULL; - /* Copy the string so that we can modify the copy as we parse it. */ - scontext2 = kmalloc(scontext_len + 1, gfp_flags); - if (!scontext2) - return -ENOMEM; - memcpy(scontext2, scontext, scontext_len); - scontext2[scontext_len] = 0; - if (force) { /* Save another copy for storing in uninterpreted form */ rc = -ENOMEM; Patches currently in stable-queue which might be from paul(a)paul-moore.com are queue-4.9/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch queue-4.9/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch

7 years, 4 months

1
0
0 0

Patch "sctp: set frag_point in sctp_setsockopt_maxseg correctly" 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 sctp: set frag_point in sctp_setsockopt_maxseg correctly 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: sctp-set-frag_point-in-sctp_setsockopt_maxseg-correctly.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 ecca8f88da5c4260cc2bccfefd2a24976704c366 Mon Sep 17 00:00:00 2001 From: Xin Long <lucien.xin(a)gmail.com> Date: Fri, 17 Nov 2017 14:11:11 +0800 Subject: sctp: set frag_point in sctp_setsockopt_maxseg correctly From: Xin Long <lucien.xin(a)gmail.com> commit ecca8f88da5c4260cc2bccfefd2a24976704c366 upstream. Now in sctp_setsockopt_maxseg user_frag or frag_point can be set with val >= 8 and val <= SCTP_MAX_CHUNK_LEN. But both checks are incorrect. val >= 8 means frag_point can even be less than SCTP_DEFAULT_MINSEGMENT. Then in sctp_datamsg_from_user(), when it's value is greater than cookie echo len and trying to bundle with cookie echo chunk, the first_len will overflow. The worse case is when it's value is equal as cookie echo len, first_len becomes 0, it will go into a dead loop for fragment later on. In Hangbin syzkaller testing env, oom was even triggered due to consecutive memory allocation in that loop. Besides, SCTP_MAX_CHUNK_LEN is the max size of the whole chunk, it should deduct the data header for frag_point or user_frag check. This patch does a proper check with SCTP_DEFAULT_MINSEGMENT subtracting the sctphdr and datahdr, SCTP_MAX_CHUNK_LEN subtracting datahdr when setting frag_point via sockopt. It also improves sctp_setsockopt_maxseg codes. Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Reported-by: Hangbin Liu <liuhangbin(a)gmail.com> Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/net/sctp/sctp.h | 3 ++- net/sctp/socket.c | 29 +++++++++++++++++++---------- 2 files changed, 21 insertions(+), 11 deletions(-) --- a/include/net/sctp/sctp.h +++ b/include/net/sctp/sctp.h @@ -433,7 +433,8 @@ static inline int sctp_frag_point(const if (asoc->user_frag) frag = min_t(int, frag, asoc->user_frag); - frag = SCTP_TRUNC4(min_t(int, frag, SCTP_MAX_CHUNK_LEN)); + frag = SCTP_TRUNC4(min_t(int, frag, SCTP_MAX_CHUNK_LEN - + sizeof(struct sctp_data_chunk))); return frag; } --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -3125,9 +3125,9 @@ static int sctp_setsockopt_mappedv4(stru */ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned int optlen) { + struct sctp_sock *sp = sctp_sk(sk); struct sctp_assoc_value params; struct sctp_association *asoc; - struct sctp_sock *sp = sctp_sk(sk); int val; if (optlen == sizeof(int)) { @@ -3143,26 +3143,35 @@ static int sctp_setsockopt_maxseg(struct if (copy_from_user(&params, optval, optlen)) return -EFAULT; val = params.assoc_value; - } else + } else { return -EINVAL; + } - if ((val != 0) && ((val < 8) || (val > SCTP_MAX_CHUNK_LEN))) - return -EINVAL; + if (val) { + int min_len, max_len; - asoc = sctp_id2assoc(sk, params.assoc_id); - if (!asoc && params.assoc_id && sctp_style(sk, UDP)) - return -EINVAL; + min_len = SCTP_DEFAULT_MINSEGMENT - sp->pf->af->net_header_len; + min_len -= sizeof(struct sctphdr) + + sizeof(struct sctp_data_chunk); + + max_len = SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_data_chunk); + if (val < min_len || val > max_len) + return -EINVAL; + } + + asoc = sctp_id2assoc(sk, params.assoc_id); if (asoc) { if (val == 0) { - val = asoc->pathmtu; - val -= sp->pf->af->net_header_len; + val = asoc->pathmtu - sp->pf->af->net_header_len; val -= sizeof(struct sctphdr) + - sizeof(struct sctp_data_chunk); + sizeof(struct sctp_data_chunk); } asoc->user_frag = val; asoc->frag_point = sctp_frag_point(asoc, asoc->pathmtu); } else { + if (params.assoc_id && sctp_style(sk, UDP)) + return -EINVAL; sp->user_frag = val; } Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are queue-4.9/sctp-set-frag_point-in-sctp_setsockopt_maxseg-correctly.patch

7 years, 4 months

1
0
0 0

Patch "rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete" 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 rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete 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: rds-tcp-atomically-purge-entries-from-rds_tcp_conn_list-during-netns-delete.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 f10b4cff98c6977668434fbf5dd58695eeca2897 Mon Sep 17 00:00:00 2001 From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> Date: Thu, 30 Nov 2017 11:11:29 -0800 Subject: rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> commit f10b4cff98c6977668434fbf5dd58695eeca2897 upstream. The rds_tcp_kill_sock() function parses the rds_tcp_conn_list to find the rds_connection entries marked for deletion as part of the netns deletion under the protection of the rds_tcp_conn_lock. Since the rds_tcp_conn_list tracks rds_tcp_connections (which have a 1:1 mapping with rds_conn_path), multiple tc entries in the rds_tcp_conn_list will map to a single rds_connection, and will be deleted as part of the rds_conn_destroy() operation that is done outside the rds_tcp_conn_lock. The rds_tcp_conn_list traversal done under the protection of rds_tcp_conn_lock should not leave any doomed tc entries in the list after the rds_tcp_conn_lock is released, else another concurrently executiong netns delete (for a differnt netns) thread may trip on these entries. Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/tcp.c | 9 +++++++-- net/rds/tcp.h | 1 + 2 files changed, 8 insertions(+), 2 deletions(-) --- a/net/rds/tcp.c +++ b/net/rds/tcp.c @@ -303,7 +303,8 @@ static void rds_tcp_conn_free(void *arg) rdsdebug("freeing tc %p\n", tc); spin_lock_irqsave(&rds_tcp_conn_lock, flags); - list_del(&tc->t_tcp_node); + if (!tc->t_tcp_node_detached) + list_del(&tc->t_tcp_node); spin_unlock_irqrestore(&rds_tcp_conn_lock, flags); kmem_cache_free(rds_tcp_conn_slab, tc); @@ -528,8 +529,12 @@ static void rds_tcp_kill_sock(struct net if (net != c_net || !tc->t_sock) continue; - if (!list_has_conn(&tmp_list, tc->t_cpath->cp_conn)) + if (!list_has_conn(&tmp_list, tc->t_cpath->cp_conn)) { list_move_tail(&tc->t_tcp_node, &tmp_list); + } else { + list_del(&tc->t_tcp_node); + tc->t_tcp_node_detached = true; + } } spin_unlock_irq(&rds_tcp_conn_lock); list_for_each_entry_safe(tc, _tc, &tmp_list, t_tcp_node) { --- a/net/rds/tcp.h +++ b/net/rds/tcp.h @@ -11,6 +11,7 @@ struct rds_tcp_incoming { struct rds_tcp_connection { struct list_head t_tcp_node; + bool t_tcp_node_detached; struct rds_conn_path *t_cpath; /* t_conn_path_lock synchronizes the connection establishment between * rds_tcp_accept_one and rds_tcp_conn_path_connect Patches currently in stable-queue which might be from sowmini.varadhan(a)oracle.com are queue-4.9/rds-tcp-atomically-purge-entries-from-rds_tcp_conn_list-during-netns-delete.patch

7 years, 4 months

1
0
0 0

Patch "ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE" 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 ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE 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: ptr_ring-fail-early-if-queue-occupies-more-than-kmalloc_max_size.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 6e6e41c3112276288ccaf80c70916779b84bb276 Mon Sep 17 00:00:00 2001 From: Jason Wang <jasowang(a)redhat.com> Date: Fri, 9 Feb 2018 17:45:49 +0800 Subject: ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE From: Jason Wang <jasowang(a)redhat.com> commit 6e6e41c3112276288ccaf80c70916779b84bb276 upstream. To avoid slab to warn about exceeded size, fail early if queue occupies more than KMALLOC_MAX_SIZE. Reported-by: syzbot+e4d4f9ddd4295539735d(a)syzkaller.appspotmail.com Fixes: 2e0ab8ca83c12 ("ptr_ring: array based FIFO for pointers") Signed-off-by: Jason Wang <jasowang(a)redhat.com> Acked-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/ptr_ring.h | 2 ++ 1 file changed, 2 insertions(+) --- a/include/linux/ptr_ring.h +++ b/include/linux/ptr_ring.h @@ -351,6 +351,8 @@ static inline void *ptr_ring_consume_bh( static inline void **__ptr_ring_init_queue_alloc(unsigned int size, gfp_t gfp) { + if (size * sizeof(void *) > KMALLOC_MAX_SIZE) + return NULL; return kcalloc(size, sizeof(void *), gfp); } Patches currently in stable-queue which might be from jasowang(a)redhat.com are queue-4.9/vhost-use-mutex_lock_nested-in-vhost_dev_lock_vqs.patch queue-4.9/ptr_ring-fail-early-if-queue-occupies-more-than-kmalloc_max_size.patch

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror