February 2018 - Linux-stable-mirror

Patch "xfrm: fix rcu usage in xfrm_get_type_offload" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfrm: fix rcu usage in xfrm_get_type_offload 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: xfrm-fix-rcu-usage-in-xfrm_get_type_offload.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 2f10a61cee8fdb9f8da90f5db687e1862b22cf06 Mon Sep 17 00:00:00 2001 From: Sabrina Dubroca <sd(a)queasysnail.net> Date: Sun, 31 Dec 2017 16:18:56 +0100 Subject: xfrm: fix rcu usage in xfrm_get_type_offload From: Sabrina Dubroca <sd(a)queasysnail.net> commit 2f10a61cee8fdb9f8da90f5db687e1862b22cf06 upstream. request_module can sleep, thus we cannot hold rcu_read_lock() while calling it. The function also jumps back and takes rcu_read_lock() again (in xfrm_state_get_afinfo()), resulting in an imbalance. This codepath is triggered whenever a new offloaded state is created. Fixes: ffdb5211da1c ("xfrm: Auto-load xfrm offload modules") Reported-by: syzbot+ca425f44816d749e8eb49755567a75ee48cf4a30(a)syzkaller.appspotmail.com Signed-off-by: Sabrina Dubroca <sd(a)queasysnail.net> Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/xfrm/xfrm_state.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/net/xfrm/xfrm_state.c +++ b/net/xfrm/xfrm_state.c @@ -313,13 +313,14 @@ retry: if ((type && !try_module_get(type->owner))) type = NULL; + rcu_read_unlock(); + if (!type && try_load) { request_module("xfrm-offload-%d-%d", family, proto); try_load = 0; goto retry; } - rcu_read_unlock(); return type; } Patches currently in stable-queue which might be from sd(a)queasysnail.net are queue-4.14/xfrm-fix-rcu-usage-in-xfrm_get_type_offload.patch

6 years, 10 months

1
0
0 0

Patch "xfrm: Fix stack-out-of-bounds read on socket policy lookup." has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfrm: Fix stack-out-of-bounds read on socket policy lookup. 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: xfrm-fix-stack-out-of-bounds-read-on-socket-policy-lookup.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 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 @@ -1168,9 +1168,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.14/xfrm-fix-stack-out-of-bounds-read-on-socket-policy-lookup.patch queue-4.14/xfrm-skip-policies-marked-as-dead-while-rehashing.patch queue-4.14/xfrm-fix-rcu-usage-in-xfrm_get_type_offload.patch queue-4.14/esp-fix-gro-when-the-headers-not-fully-in-the-linear-part-of-the-skb.patch queue-4.14/xfrm-don-t-call-xfrm_policy_cache_flush-while-holding-spinlock.patch queue-4.14/xfrm-check-id-proto-in-validate_tmpl.patch

6 years, 10 months

1
0
0 0

Patch "xfrm: check id proto in validate_tmpl()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfrm: check id proto in validate_tmpl() 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: xfrm-check-id-proto-in-validate_tmpl.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 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 @@ -1443,6 +1443,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.14/net_sched-gen_estimator-fix-lockdep-splat.patch queue-4.14/netfilter-xt_cgroup-initialize-info-priv-in-cgroup_mt_check_v1.patch queue-4.14/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch queue-4.14/xfrm-check-id-proto-in-validate_tmpl.patch

6 years, 10 months

1
0
0 0

Patch "xfrm: don't call xfrm_policy_cache_flush while holding spinlock" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfrm: don't call xfrm_policy_cache_flush while holding spinlock 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: xfrm-don-t-call-xfrm_policy_cache_flush-while-holding-spinlock.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 b1bdcb59b64f806ef08d25a85c39ffb3ad841ce6 Mon Sep 17 00:00:00 2001 From: Florian Westphal <fw(a)strlen.de> Date: Sat, 6 Jan 2018 01:13:08 +0100 Subject: xfrm: don't call xfrm_policy_cache_flush while holding spinlock From: Florian Westphal <fw(a)strlen.de> commit b1bdcb59b64f806ef08d25a85c39ffb3ad841ce6 upstream. xfrm_policy_cache_flush can sleep, so it cannot be called while holding a spinlock. We could release the lock first, but I don't see why we need to invoke this function here in first place, the packet path won't reuse an xdst entry unless its still valid. While at it, add an annotation to xfrm_policy_cache_flush, it would have probably caught this bug sooner. Fixes: ec30d78c14a813 ("xfrm: add xdst pcpu cache") Reported-by: syzbot+e149f7d1328c26f9c12f(a)syzkaller.appspotmail.com Signed-off-by: Florian Westphal <fw(a)strlen.de> 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 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -975,8 +975,6 @@ int xfrm_policy_flush(struct net *net, u } if (!cnt) err = -ESRCH; - else - xfrm_policy_cache_flush(); out: spin_unlock_bh(&net->xfrm.xfrm_policy_lock); return err; @@ -1738,6 +1736,8 @@ void xfrm_policy_cache_flush(void) bool found = 0; int cpu; + might_sleep(); + local_bh_disable(); rcu_read_lock(); for_each_possible_cpu(cpu) { Patches currently in stable-queue which might be from fw(a)strlen.de are queue-4.14/xfrm-skip-policies-marked-as-dead-while-rehashing.patch queue-4.14/netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch queue-4.14/netfilter-on-sockopt-acquire-sock-lock-only-in-the-required-scope.patch queue-4.14/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch queue-4.14/xfrm-don-t-call-xfrm_policy_cache_flush-while-holding-spinlock.patch

6 years, 10 months

1
0
0 0

Patch "usb: core: Add a helper function to check the validity of EP type in URB" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: core: Add a helper function to check the validity of EP type in URB 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: usb-core-add-a-helper-function-to-check-the-validity-of-ep-type-in-urb.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 e901b9873876ca30a09253731bd3a6b00c44b5b0 Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Wed, 4 Oct 2017 16:15:59 +0200 Subject: usb: core: Add a helper function to check the validity of EP type in URB From: Takashi Iwai <tiwai(a)suse.de> commit e901b9873876ca30a09253731bd3a6b00c44b5b0 upstream. This patch adds a new helper function to perform a sanity check of the given URB to see whether it contains a valid endpoint. It's a light- weight version of what usb_submit_urb() does, but without the kernel warning followed by the stack trace, just returns an error code. Especially for a driver that doesn't parse the descriptor but fills the URB with the fixed endpoint (e.g. some quirks for non-compliant devices), this kind of check is preferable at the probe phase before actually submitting the urb. Tested-by: Andrey Konovalov <andreyknvl(a)google.com> Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/urb.c | 30 ++++++++++++++++++++++++++---- include/linux/usb.h | 2 ++ 2 files changed, 28 insertions(+), 4 deletions(-) --- a/drivers/usb/core/urb.c +++ b/drivers/usb/core/urb.c @@ -187,6 +187,31 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb); /*-------------------------------------------------------------------*/ +static const int pipetypes[4] = { + PIPE_CONTROL, PIPE_ISOCHRONOUS, PIPE_BULK, PIPE_INTERRUPT +}; + +/** + * usb_urb_ep_type_check - sanity check of endpoint in the given urb + * @urb: urb to be checked + * + * This performs a light-weight sanity check for the endpoint in the + * given urb. It returns 0 if the urb contains a valid endpoint, otherwise + * a negative error code. + */ +int usb_urb_ep_type_check(const struct urb *urb) +{ + const struct usb_host_endpoint *ep; + + ep = usb_pipe_endpoint(urb->dev, urb->pipe); + if (!ep) + return -EINVAL; + if (usb_pipetype(urb->pipe) != pipetypes[usb_endpoint_type(&ep->desc)]) + return -EINVAL; + return 0; +} +EXPORT_SYMBOL_GPL(usb_urb_ep_type_check); + /** * usb_submit_urb - issue an asynchronous transfer request for an endpoint * @urb: pointer to the urb describing the request @@ -326,9 +351,6 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb); */ int usb_submit_urb(struct urb *urb, gfp_t mem_flags) { - static int pipetypes[4] = { - PIPE_CONTROL, PIPE_ISOCHRONOUS, PIPE_BULK, PIPE_INTERRUPT - }; int xfertype, max; struct usb_device *dev; struct usb_host_endpoint *ep; @@ -444,7 +466,7 @@ int usb_submit_urb(struct urb *urb, gfp_ */ /* Check that the pipe's type matches the endpoint's type */ - if (usb_pipetype(urb->pipe) != pipetypes[xfertype]) + if (usb_urb_ep_type_check(urb)) dev_WARN(&dev->dev, "BOGUS urb xfer, pipe %x != type %x\n", usb_pipetype(urb->pipe), pipetypes[xfertype]); --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -1729,6 +1729,8 @@ static inline int usb_urb_dir_out(struct return (urb->transfer_flags & URB_DIR_MASK) == URB_DIR_OUT; } +int usb_urb_ep_type_check(const struct urb *urb); + void *usb_alloc_coherent(struct usb_device *dev, size_t size, gfp_t mem_flags, dma_addr_t *dma); void usb_free_coherent(struct usb_device *dev, size_t size, Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.14/alsa-bcd2000-add-a-sanity-check-for-invalid-eps.patch queue-4.14/alsa-caiaq-add-a-sanity-check-for-invalid-eps.patch queue-4.14/alsa-line6-add-a-sanity-check-for-invalid-eps.patch queue-4.14/usb-core-add-a-helper-function-to-check-the-validity-of-ep-type-in-urb.patch

6 years, 10 months

1
0
0 0

Patch "vhost: use mutex_lock_nested() in vhost_dev_lock_vqs()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vhost: use mutex_lock_nested() in vhost_dev_lock_vqs() 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: vhost-use-mutex_lock_nested-in-vhost_dev_lock_vqs.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 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 @@ -904,7 +904,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.14/ptr_ring-try-vmalloc-when-kmalloc-fails.patch queue-4.14/vhost-use-mutex_lock_nested-in-vhost_dev_lock_vqs.patch queue-4.14/ptr_ring-fail-early-if-queue-occupies-more-than-kmalloc_max_size.patch

6 years, 10 months

1
0
0 0

Patch "staging: android: ion: Add __GFP_NOWARN for system contig heap" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: android: ion: Add __GFP_NOWARN for system contig heap 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: staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.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 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 @@ -371,7 +371,7 @@ static int ion_system_contig_heap_alloca unsigned long i; int ret; - 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.14/staging-android-ion-switch-from-warn-to-pr_warn.patch queue-4.14/staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.patch

6 years, 10 months

1
0
0 0

Patch "staging: android: ion: Switch from WARN to pr_warn" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: android: ion: Switch from WARN to pr_warn 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: staging-android-ion-switch-from-warn-to-pr_warn.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 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 @@ -71,8 +71,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.14/staging-android-ion-switch-from-warn-to-pr_warn.patch queue-4.14/staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.patch

6 years, 10 months

1
0
0 0

Patch "selinux: skip bounded transition processing if the policy isn't loaded" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selinux: skip bounded transition processing if the policy isn't loaded 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: selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.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 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 @@ -867,6 +867,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.14/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch queue-4.14/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch

6 years, 10 months

1
0
0 0

Patch "sctp: set frag_point in sctp_setsockopt_maxseg correctly" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sctp: set frag_point in sctp_setsockopt_maxseg correctly 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: sctp-set-frag_point-in-sctp_setsockopt_maxseg-correctly.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 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 @@ -444,7 +444,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 @@ -3136,9 +3136,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)) { @@ -3154,26 +3154,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.14/sctp-set-frag_point-in-sctp_setsockopt_maxseg-correctly.patch

6 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2018