This is a note to let you know that I've just added the patch titled
blk_rq_map_user_iov: fix error override
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:
blk_rq_map_user_iov-fix-error-override.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 69e0927b3774563c19b5fb32e91d75edc147fb62 Mon Sep 17 00:00:00 2001
From: Douglas Gilbert <dgilbert(a)interlog.com>
Date: Sun, 14 Jan 2018 17:00:48 -0500
Subject: blk_rq_map_user_iov: fix error override
From: Douglas Gilbert <dgilbert(a)interlog.com>
commit 69e0927b3774563c19b5fb32e91d75edc147fb62 upstream.
During stress tests by syzkaller on the sg driver the block layer
infrequently returns EINVAL. Closer inspection shows the block
layer was trying to return ENOMEM (which is much more
understandable) but for some reason overroad that useful error.
Patch below does not show this (unchanged) line:
ret =__blk_rq_map_user_iov(rq, map_data, &i, gfp_mask, copy);
That 'ret' was being overridden when that function failed.
Signed-off-by: Douglas Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-map.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/block/blk-map.c
+++ b/block/blk-map.c
@@ -119,7 +119,7 @@ int blk_rq_map_user_iov(struct request_q
unsigned long align = q->dma_pad_mask | queue_dma_alignment(q);
struct bio *bio = NULL;
struct iov_iter i;
- int ret;
+ int ret = -EINVAL;
if (!iter_is_iovec(iter))
goto fail;
@@ -148,7 +148,7 @@ unmap_rq:
__blk_rq_unmap_user(bio);
fail:
rq->bio = NULL;
- return -EINVAL;
+ return ret;
}
EXPORT_SYMBOL(blk_rq_map_user_iov);
Patches currently in stable-queue which might be from dgilbert(a)interlog.com are
queue-4.15/blk_rq_map_user_iov-fix-error-override.patch
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.4-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.4 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
@@ -1402,6 +1402,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.4/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
queue-4.4/xfrm-check-id-proto-in-validate_tmpl.patch
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.4-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.4 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
@@ -1225,9 +1225,15 @@ static struct xfrm_policy *xfrm_sk_polic
read_lock_bh(&net->xfrm.xfrm_policy_lock);
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.4/xfrm-fix-stack-out-of-bounds-read-on-socket-policy-lookup.patch
queue-4.4/xfrm-check-id-proto-in-validate_tmpl.patch
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.4-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.4 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
@@ -336,7 +336,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.4/staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.patch
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.4-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.4 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
@@ -860,6 +860,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.4/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch
queue-4.4/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch
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.4-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.4 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
@@ -1406,27 +1406,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.4/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch
queue-4.4/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch
This is a note to let you know that I've just added the patch titled
Provide a function to create a NUL-terminated string from unterminated data
to the 4.4-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:
provide-a-function-to-create-a-nul-terminated-string-from-unterminated-data.patch
and it can be found in the queue-4.4 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 f35157417215ec138c920320c746fdb3e04ef1d5 Mon Sep 17 00:00:00 2001
From: David Howells <dhowells(a)redhat.com>
Date: Tue, 4 Jul 2017 17:25:02 +0100
Subject: Provide a function to create a NUL-terminated string from unterminated data
From: David Howells <dhowells(a)redhat.com>
commit f35157417215ec138c920320c746fdb3e04ef1d5 upstream.
Provide a function, kmemdup_nul(), that will create a NUL-terminated string
from an unterminated character array where the length is known in advance.
This is better than kstrndup() in situations where we already know the
string length as the strnlen() in kstrndup() is superfluous.
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/string.h | 1 +
mm/util.c | 24 ++++++++++++++++++++++++
2 files changed, 25 insertions(+)
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -122,6 +122,7 @@ extern char *kstrdup(const char *s, gfp_
extern const char *kstrdup_const(const char *s, gfp_t gfp);
extern char *kstrndup(const char *s, size_t len, gfp_t gfp);
extern void *kmemdup(const void *src, size_t len, gfp_t gfp);
+extern char *kmemdup_nul(const char *s, size_t len, gfp_t gfp);
extern char **argv_split(gfp_t gfp, const char *str, int *argcp);
extern void argv_free(char **argv);
--- a/mm/util.c
+++ b/mm/util.c
@@ -80,6 +80,8 @@ EXPORT_SYMBOL(kstrdup_const);
* @s: the string to duplicate
* @max: read at most @max chars from @s
* @gfp: the GFP mask used in the kmalloc() call when allocating memory
+ *
+ * Note: Use kmemdup_nul() instead if the size is known exactly.
*/
char *kstrndup(const char *s, size_t max, gfp_t gfp)
{
@@ -118,6 +120,28 @@ void *kmemdup(const void *src, size_t le
EXPORT_SYMBOL(kmemdup);
/**
+ * kmemdup_nul - Create a NUL-terminated string from unterminated data
+ * @s: The data to stringify
+ * @len: The size of the data
+ * @gfp: the GFP mask used in the kmalloc() call when allocating memory
+ */
+char *kmemdup_nul(const char *s, size_t len, gfp_t gfp)
+{
+ char *buf;
+
+ if (!s)
+ return NULL;
+
+ buf = kmalloc_track_caller(len + 1, gfp);
+ if (buf) {
+ memcpy(buf, s, len);
+ buf[len] = '\0';
+ }
+ return buf;
+}
+EXPORT_SYMBOL(kmemdup_nul);
+
+/**
* memdup_user - duplicate memory region from user space
*
* @src: source address in user space
Patches currently in stable-queue which might be from dhowells(a)redhat.com are
queue-4.4/provide-a-function-to-create-a-nul-terminated-string-from-unterminated-data.patch
This is a note to let you know that I've just added the patch titled
netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
to the 4.4-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:
netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
and it can be found in the queue-4.4 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 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Mon, 5 Feb 2018 14:41:45 -0800
Subject: netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 upstream.
rateest_hash is supposed to be protected by xt_rateest_mutex,
and, as suggested by Eric, lookup and insert should be atomic,
so we should acquire the xt_rateest_mutex once for both.
So introduce a non-locking helper for internal use and keep the
locking one for external.
Reported-by: <syzbot+5cb189720978275e4c75(a)syzkaller.appspotmail.com>
Fixes: 5859034d7eb8 ("[NETFILTER]: x_tables: add RATEEST target")
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Reviewed-by: Florian Westphal <fw(a)strlen.de>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/xt_RATEEST.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
--- a/net/netfilter/xt_RATEEST.c
+++ b/net/netfilter/xt_RATEEST.c
@@ -40,23 +40,31 @@ static void xt_rateest_hash_insert(struc
hlist_add_head(&est->list, &rateest_hash[h]);
}
-struct xt_rateest *xt_rateest_lookup(const char *name)
+static struct xt_rateest *__xt_rateest_lookup(const char *name)
{
struct xt_rateest *est;
unsigned int h;
h = xt_rateest_hash(name);
- mutex_lock(&xt_rateest_mutex);
hlist_for_each_entry(est, &rateest_hash[h], list) {
if (strcmp(est->name, name) == 0) {
est->refcnt++;
- mutex_unlock(&xt_rateest_mutex);
return est;
}
}
- mutex_unlock(&xt_rateest_mutex);
+
return NULL;
}
+
+struct xt_rateest *xt_rateest_lookup(const char *name)
+{
+ struct xt_rateest *est;
+
+ mutex_lock(&xt_rateest_mutex);
+ est = __xt_rateest_lookup(name);
+ mutex_unlock(&xt_rateest_mutex);
+ return est;
+}
EXPORT_SYMBOL_GPL(xt_rateest_lookup);
void xt_rateest_put(struct xt_rateest *est)
@@ -104,8 +112,10 @@ static int xt_rateest_tg_checkentry(cons
rnd_inited = true;
}
- est = xt_rateest_lookup(info->name);
+ mutex_lock(&xt_rateest_mutex);
+ est = __xt_rateest_lookup(info->name);
if (est) {
+ mutex_unlock(&xt_rateest_mutex);
/*
* If estimator parameters are specified, they must match the
* existing estimator.
@@ -143,11 +153,13 @@ static int xt_rateest_tg_checkentry(cons
info->est = est;
xt_rateest_hash_insert(est);
+ mutex_unlock(&xt_rateest_mutex);
return 0;
err2:
kfree(est);
err1:
+ mutex_unlock(&xt_rateest_mutex);
return ret;
}
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.4/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
queue-4.4/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
to the 4.4-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:
netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch
and it can be found in the queue-4.4 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 da17c73b6eb74aad3c3c0654394635675b623b3e Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 24 Jan 2018 17:16:09 -0800
Subject: netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
From: Eric Dumazet <edumazet(a)google.com>
commit da17c73b6eb74aad3c3c0654394635675b623b3e upstream.
It looks like syzbot found its way into netfilter territory.
Issue here is that @name comes from user space and might
not be null terminated.
Out-of-bound reads happen, KASAN is not happy.
v2 added similar fix for xt_request_find_target(),
as Florian advised.
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Acked-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/x_tables.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -206,6 +206,9 @@ xt_request_find_match(uint8_t nfproto, c
{
struct xt_match *match;
+ if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN)
+ return ERR_PTR(-EINVAL);
+
match = xt_find_match(nfproto, name, revision);
if (IS_ERR(match)) {
request_module("%st_%s", xt_prefix[nfproto], name);
@@ -248,6 +251,9 @@ struct xt_target *xt_request_find_target
{
struct xt_target *target;
+ if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN)
+ return ERR_PTR(-EINVAL);
+
target = xt_find_target(af, name, revision);
if (IS_ERR(target)) {
request_module("%st_%s", xt_prefix[af], name);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.4/netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch
queue-4.4/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch